fix(order-book): uploadAppData returns AppDataHash, not AppDataObject - #968
fix(order-book): uploadAppData returns AppDataHash, not AppDataObject#968gomesalexandre wants to merge 1 commit into
Conversation
The orderbook API returns the appDataHash for both 200 and 201 on
PUT /api/v1/app_data/{app_data_hash}, per the OpenAPI spec this package
pins its own codegen to. We were typing it as AppDataObject.
Our own test already asserted the correct runtime shape - it mocks a
bare string and expects the result to equal the hash - so the type was
the only thing that was wrong.
Also pins the return type in the test so a regression fails tsc rather
than surviving until someone hits it at runtime.
|
All contributors have signed the CLA ✍️ ✅ |
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (2)
📝 WalkthroughWalkthrough
ChangesAppData upload return type
Estimated code review effort: 1 (Trivial) | ~5 minutes Merge Risk: ⚪ Minimal · up to The public method now accurately returns the hash string produced by the order book, with documentation and tests updated accordingly. No actionable merge-blocking risk remains after normal checks and review. Suggested reviewers: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches 💡 1🛠️ Fix failing CI checks 💡
🧪 Generate unit tests (beta)
Warning There were issues while running some tools. Please review the errors and either fix the tool's configuration or disable the tool if it's a critical failure. 🔧 ESLint
packages/order-book/src/api.spec.tsParsing error: Unable to parse the specified 'tsconfig' file. Ensure it's correct and has valid syntax. packages/app-data/tsconfig.json(2,14): error TS6053: File ' packages/order-book/src/api.tsParsing error: Unable to parse the specified 'tsconfig' file. Ensure it's correct and has valid syntax. packages/app-data/tsconfig.json(2,14): error TS6053: File ' 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 |
|
I have read the CLA Document and I hereby sign the CLA |
Closes #193
OrderBookApi.uploadAppData()is typed as returningPromise<AppDataObject>. It doesn't - the orderbook returns theappDataHash, a plain hex string.Straight from the OpenAPI spec this package pins its own codegen to (services@5341875),
PUT /api/v1/app_data/{app_data_hash}:And
AppDataHashistype: string, whileAppDataObjectis an object with afullAppDataproperty. So it's not a doc nit, the return type is just wrong.The funny part is our own test already knew.
api.spec.tsmocks a bare string and asserts the result equals the hash - it even names the variableappDataHashResult. Only the type disagreed.what changed
uploadAppDatanow returnsPromise<AppDataHash>@returnsdocblock, it claimed "the string encoding of the full app data"tscinstead of surviving until someone hits it at runtimeNo consumer needed touching. Every call site in
trading/andbridging/already ignores the return value, and the mocks resolve strings orundefined.receipts
Reverting just the return type to
AppDataObject, leaving the new assertion in place:With the fix:
risk
Low, but it is a breaking type change on a public method - anyone who wrote
const { fullAppData } = await uploadAppData(...)was already gettingundefinedat runtime, they just weren't told. Happy to land it behind a major if you'd rather.Summary by CodeRabbit