feat: Add custom http status code and headers support for cloud funct… #9979
Conversation
| I will reformat the title to use the proper commit message syntax. |
parse-github-assistant bot changed the title | 🚀 Thanks for opening this pull request! |
📝 WalkthroughWalkthroughAdds a CloudResponse helper passed as a second argument to cloud functions so functions can set custom HTTP status and headers; FunctionsRouter collects CloudResponse data and applies status/headers to outgoing responses. Tests and README documentation were added. Changes
Sequence Diagram(s)mermaid Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20–30 minutes
Pre-merge checks and finishing touches❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing touches
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
✅ Snyk checks have passed. No issues have been found so far.
💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse. |
| I'm not a fan of this implementation; it looks like manipulation a server-internal property. Exposing a response object alongside the request object would be a cleaner approach. |
Changed my approach: Added CloudResponse class and pass it as second argument to cloud functions (req, res). When res.status() or res.set() are called, FunctionsRouter.createResponseObject passes status and headers to the existing PromiseRouter infrastructure. The res argument is optional - existing functions using only (req) continue to work unchanged. Example: I do not want the bounty for this feature implementation, would just be happy if I get a tiny contribution to a project I have been using regularly! |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (4)
spec/CloudCode.spec.js (1)
96-185: Consider adding edge case tests.While the current tests provide good coverage, consider adding tests for edge cases:
- Invalid status codes (negative numbers, strings, out of valid HTTP range)
- Calling
res.status()multiple times (last wins?)- Setting the same header multiple times
- Invalid header names (non-string values)
These tests would ensure robust error handling and clarify expected behavior.
src/Routers/FunctionsRouter.js (3)
18-24: Add HTTP status code range validation.The current validation only checks if the status code is a number, but doesn't validate it's a valid HTTP status code. Consider adding range validation:
status(code) { if (typeof code !== 'number') { throw new Error('Status code must be a number'); } + if (code < 100 || code > 599) { + throw new Error('Status code must be between 100 and 599'); + } this._status = code; return this; }
26-32: Consider adding header value validation.The
set()method doesn't validate that thevalueparameter is defined or of an appropriate type. While HTTP headers are typically strings, consider adding basic validation:set(name, value) { if (typeof name !== 'string') { throw new Error('Header name must be a string'); } + if (value === undefined || value === null) { + throw new Error('Header value must be defined'); + } this._headers[name] = value; return this; }
149-158: Consider defensive copying of headers object.Line 156 directly assigns the headers object from
cloudResponse.getHeaders(), which could lead to unintended mutations if the internal_headersobject is modified after resolution. Consider creating a shallow copy:if (Object.keys(headers).length > 0) { - response.headers = headers; + response.headers = { ...headers }; }
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
spec/CloudCode.spec.js(1 hunks)src/Routers/FunctionsRouter.js(4 hunks)
🧰 Additional context used
🧠 Learnings (7)
📓 Common learnings
Learnt from: mtrezza Repo: parse-community/parse-server PR: 0 File: :0-0 Timestamp: 2025-11-08T13:46:04.940Z Learning: When reviewing Parse Server PRs that add new features, always check whether the feature is documented in the README.md file, though for new Parse Server options this is optional rather than required. Learnt from: mtrezza Repo: parse-community/parse-server PR: 0 File: :0-0 Timestamp: 2025-11-17T15:02:48.786Z Learning: For Parse Server PRs, always suggest an Angular commit convention PR title that would make a meaningful changelog entry for developers. Update the PR title suggestion on every commit. The format should be: type(scope): description. Common types include feat, fix, perf, refactor, docs, test, chore. The scope should identify the subsystem (e.g., graphql, rest, push, security). The description should be action-oriented and clearly convey the change's impact to developers. 📚 Learning: 2025-10-16T19:27:05.311Z
Learnt from: Moumouls Repo: parse-community/parse-server PR: 9883 File: spec/CloudCodeLogger.spec.js:410-412 Timestamp: 2025-10-16T19:27:05.311Z Learning: In spec/CloudCodeLogger.spec.js, the test "should log cloud function triggers using the silent log level" (around lines 383-420) is known to be flaky and requires the extra `await new Promise(resolve => setTimeout(resolve, 100))` timeout after awaiting `afterSavePromise` for reliability, even though it may appear redundant. Applied to files:
spec/CloudCode.spec.js
📚 Learning: 2025-08-27T09:08:34.252Z
Learnt from: EmpiDev Repo: parse-community/parse-server PR: 9770 File: src/triggers.js:446-454 Timestamp: 2025-08-27T09:08:34.252Z Learning: When analyzing function signature changes in Parse Server codebase, verify that call sites are actually incorrect before flagging them. Passing tests are a strong indicator that function calls are already properly aligned with new signatures. Applied to files:
spec/CloudCode.spec.js
📚 Learning: 2025-05-09T09:59:06.289Z
Learnt from: mtrezza Repo: parse-community/parse-server PR: 9445 File: spec/ParseLiveQuery.spec.js:1340-1375 Timestamp: 2025-05-09T09:59:06.289Z Learning: New tests in the parse-server repository should use async/await with promise-based patterns rather than callback patterns with `done()`. The preferred pattern is to create a Promise that resolves when an expected event occurs, then await that Promise. Applied to files:
spec/CloudCode.spec.jssrc/Routers/FunctionsRouter.js
📚 Learning: 2025-05-09T09:59:06.289Z
Learnt from: mtrezza Repo: parse-community/parse-server PR: 9445 File: spec/ParseLiveQuery.spec.js:1340-1375 Timestamp: 2025-05-09T09:59:06.289Z Learning: Tests in the parse-server repository should use promise-based approaches rather than callback patterns with `done()`. Use a pattern where a Promise is created that resolves when the event occurs, then await that promise. Applied to files:
spec/CloudCode.spec.jssrc/Routers/FunctionsRouter.js
📚 Learning: 2025-05-04T20:41:05.147Z
Learnt from: mtrezza Repo: parse-community/parse-server PR: 9445 File: spec/ParseLiveQuery.spec.js:1312-1338 Timestamp: 2025-05-04T20:41:05.147Z Learning: New tests in the parse-server repository should use async/await with promise-based patterns rather than callback patterns with `done()`. Applied to files:
spec/CloudCode.spec.js
📚 Learning: 2025-04-30T19:31:35.344Z
Learnt from: RahulLanjewar93 Repo: parse-community/parse-server PR: 9744 File: spec/ParseLiveQuery.spec.js:0-0 Timestamp: 2025-04-30T19:31:35.344Z Learning: In the Parse Server codebase, the functions in QueryTools.js are typically tested through end-to-end behavior tests rather than direct unit tests, even though the functions are exported from the module. Applied to files:
spec/CloudCode.spec.js
🧬 Code graph analysis (1)
src/Routers/FunctionsRouter.js (1)
src/PromiseRouter.js (1)
headers(143-143)
🔇 Additional comments (5)
spec/CloudCode.spec.js (4)
96-115: LGTM! Well-structured test for custom HTTP status codes.The test correctly validates that cloud functions can return a custom 201 status code while maintaining the standard result payload structure.
117-139: LGTM! Good coverage of custom header functionality.The test correctly validates multiple custom headers and properly handles HTTP header case-insensitivity by checking the lowercase versions.
166-185: Excellent backward compatibility test.This test is critical for ensuring existing cloud functions that return objects containing
statusorresultfields continue to work without those fields being misinterpreted as response metadata. The assertions correctly verify the returned object is nested underresponse.data.result.
141-164: The response payload structure in this test is correct. Theresponse.data.result.erroraccess (line 162) follows the standard Parse Server Cloud Function response format, as confirmed by consistent usage across multiple tests in the same file (lines 114, 138, 183-184). No changes needed.src/Routers/FunctionsRouter.js (1)
177-177: Note: Cloud jobs don't receive custom status/header capability.The
CloudResponsefunctionality is only implemented for cloud functions (viahandleCloudFunction), not for cloud jobs (viahandleCloudJob). If this is intentional scope limitation, consider documenting it. If custom status/headers should also apply to jobs, the implementation needs to be extended.
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (1)
spec/CloudCode.spec.js (1)
96-322: Nice coverage for the new CloudResponse behavior (status, headers, edge cases).
Optional: consider a tiny helper for the repeatedrequest({ method, url, headers, body })blocks to keep the suite easier to extend.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (3)
README.md(1 hunks)spec/CloudCode.spec.js(1 hunks)src/Routers/FunctionsRouter.js(4 hunks)
🧰 Additional context used
🧠 Learnings (10)
📓 Common learnings
Learnt from: mtrezza Repo: parse-community/parse-server PR: 0 File: :0-0 Timestamp: 2025-11-08T13:46:04.940Z Learning: When reviewing Parse Server PRs that add new features, always check whether the feature is documented in the README.md file, though for new Parse Server options this is optional rather than required. Learnt from: mtrezza Repo: parse-community/parse-server PR: 0 File: :0-0 Timestamp: 2025-11-17T15:02:48.786Z Learning: For Parse Server PRs, always suggest an Angular commit convention PR title that would make a meaningful changelog entry for developers. Update the PR title suggestion on every commit. The format should be: type(scope): description. Common types include feat, fix, perf, refactor, docs, test, chore. The scope should identify the subsystem (e.g., graphql, rest, push, security). The description should be action-oriented and clearly convey the change's impact to developers. 📚 Learning: 2025-10-16T19:27:05.311Z
Learnt from: Moumouls Repo: parse-community/parse-server PR: 9883 File: spec/CloudCodeLogger.spec.js:410-412 Timestamp: 2025-10-16T19:27:05.311Z Learning: In spec/CloudCodeLogger.spec.js, the test "should log cloud function triggers using the silent log level" (around lines 383-420) is known to be flaky and requires the extra `await new Promise(resolve => setTimeout(resolve, 100))` timeout after awaiting `afterSavePromise` for reliability, even though it may appear redundant. Applied to files:
spec/CloudCode.spec.js
📚 Learning: 2025-08-27T09:08:34.252Z
Learnt from: EmpiDev Repo: parse-community/parse-server PR: 9770 File: src/triggers.js:446-454 Timestamp: 2025-08-27T09:08:34.252Z Learning: When analyzing function signature changes in Parse Server codebase, verify that call sites are actually incorrect before flagging them. Passing tests are a strong indicator that function calls are already properly aligned with new signatures. Applied to files:
spec/CloudCode.spec.js
📚 Learning: 2025-05-09T09:59:06.289Z
Learnt from: mtrezza Repo: parse-community/parse-server PR: 9445 File: spec/ParseLiveQuery.spec.js:1340-1375 Timestamp: 2025-05-09T09:59:06.289Z Learning: New tests in the parse-server repository should use async/await with promise-based patterns rather than callback patterns with `done()`. The preferred pattern is to create a Promise that resolves when an expected event occurs, then await that Promise. Applied to files:
spec/CloudCode.spec.jssrc/Routers/FunctionsRouter.js
📚 Learning: 2025-05-09T09:59:06.289Z
Learnt from: mtrezza Repo: parse-community/parse-server PR: 9445 File: spec/ParseLiveQuery.spec.js:1340-1375 Timestamp: 2025-05-09T09:59:06.289Z Learning: Tests in the parse-server repository should use promise-based approaches rather than callback patterns with `done()`. Use a pattern where a Promise is created that resolves when the event occurs, then await that promise. Applied to files:
spec/CloudCode.spec.jssrc/Routers/FunctionsRouter.js
📚 Learning: 2025-05-04T20:41:05.147Z
Learnt from: mtrezza Repo: parse-community/parse-server PR: 9445 File: spec/ParseLiveQuery.spec.js:1312-1338 Timestamp: 2025-05-04T20:41:05.147Z Learning: New tests in the parse-server repository should use async/await with promise-based patterns rather than callback patterns with `done()`. Applied to files:
spec/CloudCode.spec.js
📚 Learning: 2025-04-30T19:31:35.344Z
Learnt from: RahulLanjewar93 Repo: parse-community/parse-server PR: 9744 File: spec/ParseLiveQuery.spec.js:0-0 Timestamp: 2025-04-30T19:31:35.344Z Learning: In the Parse Server codebase, the functions in QueryTools.js are typically tested through end-to-end behavior tests rather than direct unit tests, even though the functions are exported from the module. Applied to files:
spec/CloudCode.spec.js
📚 Learning: 2025-11-08T13:46:04.940Z
Learnt from: mtrezza Repo: parse-community/parse-server PR: 0 File: :0-0 Timestamp: 2025-11-08T13:46:04.940Z Learning: For new Parse Server options, verify that the option is documented in src/Options/index.js and that npm run definitions has been executed to reflect changes in src/Options/docs.js and src/Options/Definitions.js. README.md documentation is a bonus but not required for new options. Applied to files:
README.mdsrc/Routers/FunctionsRouter.js
📚 Learning: 2025-11-08T13:46:04.940Z
Learnt from: mtrezza Repo: parse-community/parse-server PR: 0 File: :0-0 Timestamp: 2025-11-08T13:46:04.940Z Learning: When reviewing Parse Server PRs that add new features, always check whether the feature is documented in the README.md file, though for new Parse Server options this is optional rather than required. Applied to files:
src/Routers/FunctionsRouter.js
📚 Learning: 2025-12-02T06:55:53.808Z
Learnt from: mtrezza Repo: parse-community/parse-server PR: 0 File: :0-0 Timestamp: 2025-12-02T06:55:53.808Z Learning: When reviewing Parse Server PRs that add or modify Parse Server options, always verify that changes are properly reflected in three files: src/Options/index.js (where changes originate), src/Options/Definitions.js, and src/Options/docs.js. The correct workflow is: make changes in index.js first, then run `npm run definitions` to automatically replicate the changes to Definitions.js and docs.js. Applied to files:
src/Routers/FunctionsRouter.js
🔇 Additional comments (2)
src/Routers/FunctionsRouter.js (2)
147-172: Clarify/confirm semantics for “error” statuses vs thrown errors.
Customstatus/headersare only applied in thesuccess()path. If a function setsres.status(401)and then throws, the status won’t be honored (it’ll go through normal error handling). If that’s intended, it’s worth documenting explicitly (or adding a test to lock it in).
183-249: Response plumbing looks clean; signature change is pragmatic.
PassingcloudResponseas an optional second argument keeps(req) => {}handlers unaffected and matches the Express-like API described in the README/tests.
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (2)
src/Routers/FunctionsRouter.js (2)
43-48: Consider simplifying header value coercion logic.The current header value handling works correctly but could be more readable. The logic converts values to strings, wraps in an array for validation, then stores the converted value. Consider extracting this to a helper method for clarity:
_normalizeHeaderValue(value) { const normalized = Array.isArray(value) ? value.map(v => String(v)) : String(value); const values = Array.isArray(normalized) ? normalized : [normalized]; if (values.some(v => /[\r\n]/.test(v))) { throw new Error('Header value must not contain CRLF'); } return normalized; }This is optional—the current implementation is functional and well-tested.
1-1: Suggest updating PR title to follow Angular commit convention more precisely.Based on learnings, the PR title should follow the format:
type(scope): descriptionwhere the scope identifies the subsystem and the description is action-oriented.Suggested title:
feat(cloud-functions): enable custom HTTP status and headers in cloud functionsThis clearly conveys:
- Type:
feat(new feature)- Scope:
cloud-functions(the subsystem affected)- Impact: Developers can now set custom HTTP status codes and headers from cloud functions
As per coding guidelines, this makes a more meaningful changelog entry for developers.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (3)
README.md(2 hunks)spec/CloudCode.spec.js(1 hunks)src/Routers/FunctionsRouter.js(4 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
- README.md
🧰 Additional context used
🧠 Learnings (11)
📓 Common learnings
Learnt from: mtrezza Repo: parse-community/parse-server PR: 0 File: :0-0 Timestamp: 2025-11-08T13:46:04.940Z Learning: When reviewing Parse Server PRs that add new features, always check whether the feature is documented in the README.md file, though for new Parse Server options this is optional rather than required. Learnt from: mtrezza Repo: parse-community/parse-server PR: 0 File: :0-0 Timestamp: 2025-11-17T15:02:48.786Z Learning: For Parse Server PRs, always suggest an Angular commit convention PR title that would make a meaningful changelog entry for developers. Update the PR title suggestion on every commit. The format should be: type(scope): description. Common types include feat, fix, perf, refactor, docs, test, chore. The scope should identify the subsystem (e.g., graphql, rest, push, security). The description should be action-oriented and clearly convey the change's impact to developers. 📚 Learning: 2025-10-16T19:27:05.311Z
Learnt from: Moumouls Repo: parse-community/parse-server PR: 9883 File: spec/CloudCodeLogger.spec.js:410-412 Timestamp: 2025-10-16T19:27:05.311Z Learning: In spec/CloudCodeLogger.spec.js, the test "should log cloud function triggers using the silent log level" (around lines 383-420) is known to be flaky and requires the extra `await new Promise(resolve => setTimeout(resolve, 100))` timeout after awaiting `afterSavePromise` for reliability, even though it may appear redundant. Applied to files:
spec/CloudCode.spec.js
📚 Learning: 2025-08-27T09:08:34.252Z
Learnt from: EmpiDev Repo: parse-community/parse-server PR: 9770 File: src/triggers.js:446-454 Timestamp: 2025-08-27T09:08:34.252Z Learning: When analyzing function signature changes in Parse Server codebase, verify that call sites are actually incorrect before flagging them. Passing tests are a strong indicator that function calls are already properly aligned with new signatures. Applied to files:
spec/CloudCode.spec.js
📚 Learning: 2025-05-09T09:59:06.289Z
Learnt from: mtrezza Repo: parse-community/parse-server PR: 9445 File: spec/ParseLiveQuery.spec.js:1340-1375 Timestamp: 2025-05-09T09:59:06.289Z Learning: New tests in the parse-server repository should use async/await with promise-based patterns rather than callback patterns with `done()`. The preferred pattern is to create a Promise that resolves when an expected event occurs, then await that Promise. Applied to files:
spec/CloudCode.spec.jssrc/Routers/FunctionsRouter.js
📚 Learning: 2025-05-09T09:59:06.289Z
Learnt from: mtrezza Repo: parse-community/parse-server PR: 9445 File: spec/ParseLiveQuery.spec.js:1340-1375 Timestamp: 2025-05-09T09:59:06.289Z Learning: Tests in the parse-server repository should use promise-based approaches rather than callback patterns with `done()`. Use a pattern where a Promise is created that resolves when the event occurs, then await that promise. Applied to files:
spec/CloudCode.spec.jssrc/Routers/FunctionsRouter.js
📚 Learning: 2025-05-04T20:41:05.147Z
Learnt from: mtrezza Repo: parse-community/parse-server PR: 9445 File: spec/ParseLiveQuery.spec.js:1312-1338 Timestamp: 2025-05-04T20:41:05.147Z Learning: New tests in the parse-server repository should use async/await with promise-based patterns rather than callback patterns with `done()`. Applied to files:
spec/CloudCode.spec.js
📚 Learning: 2025-04-30T19:31:35.344Z
Learnt from: RahulLanjewar93 Repo: parse-community/parse-server PR: 9744 File: spec/ParseLiveQuery.spec.js:0-0 Timestamp: 2025-04-30T19:31:35.344Z Learning: In the Parse Server codebase, the functions in QueryTools.js are typically tested through end-to-end behavior tests rather than direct unit tests, even though the functions are exported from the module. Applied to files:
spec/CloudCode.spec.js
📚 Learning: 2025-11-08T13:46:04.940Z
Learnt from: mtrezza Repo: parse-community/parse-server PR: 0 File: :0-0 Timestamp: 2025-11-08T13:46:04.940Z Learning: When reviewing Parse Server PRs that add new features, always check whether the feature is documented in the README.md file, though for new Parse Server options this is optional rather than required. Applied to files:
src/Routers/FunctionsRouter.js
📚 Learning: 2025-12-02T06:55:53.808Z
Learnt from: mtrezza Repo: parse-community/parse-server PR: 0 File: :0-0 Timestamp: 2025-12-02T06:55:53.808Z Learning: When reviewing Parse Server PRs that add or modify Parse Server options, always verify that changes are properly reflected in three files: src/Options/index.js (where changes originate), src/Options/Definitions.js, and src/Options/docs.js. The correct workflow is: make changes in index.js first, then run `npm run definitions` to automatically replicate the changes to Definitions.js and docs.js. Applied to files:
src/Routers/FunctionsRouter.js
📚 Learning: 2025-11-08T13:46:04.940Z
Learnt from: mtrezza Repo: parse-community/parse-server PR: 0 File: :0-0 Timestamp: 2025-11-08T13:46:04.940Z Learning: For new Parse Server options, verify that the option is documented in src/Options/index.js and that npm run definitions has been executed to reflect changes in src/Options/docs.js and src/Options/Definitions.js. README.md documentation is a bonus but not required for new options. Applied to files:
src/Routers/FunctionsRouter.js
📚 Learning: 2025-11-17T15:02:48.786Z
Learnt from: mtrezza Repo: parse-community/parse-server PR: 0 File: :0-0 Timestamp: 2025-11-17T15:02:48.786Z Learning: For Parse Server PRs, always suggest an Angular commit convention PR title that would make a meaningful changelog entry for developers. Update the PR title suggestion on every commit. The format should be: type(scope): description. Common types include feat, fix, perf, refactor, docs, test, chore. The scope should identify the subsystem (e.g., graphql, rest, push, security). The description should be action-oriented and clearly convey the change's impact to developers. Applied to files:
src/Routers/FunctionsRouter.js
🔇 Additional comments (3)
spec/CloudCode.spec.js (1)
96-413: Excellent test coverage for CloudResponse feature.The test suite comprehensively covers:
- ✅ Happy paths: custom status codes, custom headers, combined usage
- ✅ Backward compatibility: functions that don't use the response object
- ✅ Edge cases: multiple calls (last-value semantics)
- ✅ Security validations: NaN, out-of-range status, prototype pollution headers (
__proto__,constructor,prototype), CRLF injection- ✅ Input validation: type checking for status and header names/values
All tests follow Parse Server best practices with async/await patterns (as per learnings). Well done!
src/Routers/FunctionsRouter.js (2)
12-63: Robust CloudResponse implementation with comprehensive validation.The CloudResponse class properly addresses all security concerns:
- ✅
Object.create(null)prevents prototype pollution- ✅
Number.isInteger()rejects NaN, floats, and Infinity- ✅ Status range validation (100-599) enforces valid HTTP codes
- ✅ Header name validation prevents prototype pollution and empty names
- ✅ CRLF validation prevents header injection attacks
- ✅ Fluent interface supports method chaining
The implementation is secure and well-designed.
159-184: Clean integration maintaining backward compatibility.The CloudResponse integration is well-implemented:
- The
cloudResponseparameter is optional (2nd argument), so existing cloud functions that only accept(request)continue to work unchanged- Line 167: Proper null-safety check before accessing custom response data
- Line 174: Defensive copy of headers prevents external mutation
- Lines 170-176: Conditional application ensures default behavior when no custom response is set
Backward compatibility is confirmed by the test "returns normal response when response object is not used" (spec lines 166-185).
Also applies to: 195-262
| See #9980 |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@ ## alpha #9979 +/- ## ========================================== + Coverage 92.54% 92.55% +0.01% ========================================== Files 190 190 Lines 15434 15469 +35 Branches 176 176 ========================================== + Hits 14283 14318 +35 Misses 1139 1139 Partials 12 12 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
@mtrezza did you check the changes here? Will you go with #9980? Thank you :-) |
| @hajjarjoseph I think we'll go with #9980, it also contains a new express-style syntax for composing the response. Would you want to test out that PR before we merge - if you have a use case for it? |
All good 👍 |
3 participants
Pull Request
Issue
Closes: #9479
Approach
Modified
FunctionsRouter.createResponseObjectto detect__httpResponse: truein cloud function return values and pass throughstatusandheadersto the existing PromiseRouter infrastructure. Fully backwards compatible.edited new approach:
Added CloudResponse class and pass it as second argument to cloud functions (req, res). When res.status() or res.set() are called, FunctionsRouter.createResponseObject passes status and headers to the existing PromiseRouter infrastructure. The res argument is optional - existing functions using only (req) continue to work unchanged.
Tasks
Summary by CodeRabbit
New Features
Documentation
Tests
✏️ Tip: You can customize this high-level summary in your review settings.