Skip to content

fix(sdl): report a memory or storage size without a unit as invalid input - #4033

Merged
baktun14 merged 2 commits into
mainfrom
fix/sdl-reject-size-without-unit
Sep 24, 2026
Merged

baktun14 merged 2 commits into
mainfrom
fix/sdl-reject-size-without-unit

Conversation

@baktun14

Copy link
Copy Markdown
Contributor

Why

POST /v1/deployments answered 500 for an SDL whose memory or storage size had no unit (for example "1073741824"). chain-sdk validates sizes only while building the manifest and throws a plain Error for one it cannot parse, and the API's SDL pipeline only turned YAML and schema failures into 400s, so this escaped as an unhandled error and paged the 5xx alert. Twelve such requests hit prod on 2026-09-24.

What

  • generateManifestReportingInvalidSizes wraps chain-sdk's generateManifest and converts an Invalid size string error into the validation result every other SDL problem takes, naming the value and the expected format. Any other error still propagates.
  • SdlService.generateManifestFrom goes through it, so both the unresolved and the resolved manifest paths answer 400 with Invalid SDL: memory or storage size "1073741824" must be a number with a unit, such as 512Mi or 1Gi.

…nput

chain-sdk only checks a size string while it builds the manifest, and a value it cannot
parse (for example "1073741824" with no unit) leaves generateManifest as a thrown Error
rather than a validation result. The API had no handling for it, so the request answered
500. Convert that error into the same validation result every other SDL problem takes,
naming the value and the expected format, so the request answers 400.
@baktun14
baktun14 requested a review from a team as a code owner September 24, 2026 17:33
@coderabbitai

coderabbitai Bot commented Sep 24, 2026 •

Copy link
Copy Markdown
Contributor

Warning

Review limit reached

  • Run on-demand review

This review includes 5 billable files and costs up to $1.25.

  • Ask an admin to make reviews automatic

Open in CodeRabbit

Reviews can continue after your included limit without a manual trigger. An admin must approve usage-based billing.

Or wait 37 minutes for your next included review.

Check out review usage here.

View limit details

Limit details: You’ve used all 2 included reviews currently available. Your 52 included PR review attempts over the past 7 days set your current allowance at 2 reviews per hour.

Learn how review limits work.

Review configuration:

⚙️ Run configuration

Configuration used: Repository: akash-network/console/.coderabbit.yaml

Review profile: CHILL

Plan: Essentials

Run ID: 1ae7ed1b-d915-40c5-b565-5b42c494ab57

📥 Commits

Reviewing files that changed from the base of the PR and between c52d12d and c5a320c.

📒 Files selected for processing (5)
  • apps/api/src/deployment/services/sdl/sdl.service.spec.ts
  • apps/api/src/deployment/services/sdl/sdl.service.ts
  • apps/api/src/deployment/utils/sdl-sizes/sdl-sizes.spec.ts
  • apps/api/src/deployment/utils/sdl-sizes/sdl-sizes.ts
  • apps/api/test/functional/deployments.spec.ts

Comment @coderabbitai help to get the list of available commands.

@codecov

codecov Bot commented Sep 24, 2026

Copy link
Copy Markdown

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 87.59%. Comparing base (c52d12d) to head (c5a320c).
✅ All tests successful. No failed tests found.

Additional details and impacted files
@@            Coverage Diff             @@
##             main    #4033      +/-   ##
==========================================
- Coverage   87.74%   87.59%   -0.16%     
==========================================
  Files        1281     1177     -104     
  Lines       36066    33394    -2672     
  Branches     8576     8048     -528     
==========================================
- Hits        31647    29250    -2397     
+ Misses       3911     3654     -257     
+ Partials      508      490      -18     
Flag Coverage Δ *Carryforward flag
api 93.46% <100.00%> (-0.01%) ⬇️
deploy-web 81.79% <ø> (ø) Carriedforward from c52d12d
log-collector ?
notifications 94.35% <ø> (ø) Carriedforward from c52d12d
provider-console 81.68% <ø> (ø) Carriedforward from c52d12d
provider-inventory ?
provider-proxy 89.16% <ø> (ø) Carriedforward from c52d12d
tx-signer ?

*This pull request uses carry forward flags. Click here to find out more.

Files with missing lines Coverage Δ
...pps/api/src/deployment/services/sdl/sdl.service.ts 98.57% <100.00%> (ø)
...ps/api/src/deployment/utils/sdl-sizes/sdl-sizes.ts 100.00% <100.00%> (ø)

... and 107 files with indirect coverage changes

🚀 New features to boost your workflow:
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

@claude claude Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM — straightforward, well-tested bug fix.

What was reviewed: the new generateManifestReportingInvalidSizes wrapper (narrow catch on the Invalid size string: prefix, rethrows anything else); its wiring into SdlService.generateManifestFrom; and the new instancePath/message match the existing /profiles/compute and Invalid SDL: ${message} conventions already used elsewhere in sdl.service.ts and deployment-writer.service.ts. Coverage spans unit (sdl-sizes.spec.ts), service (sdl.service.spec.ts), and functional (deployments.spec.ts) levels, and the new tests follow the repo's setup() convention already used in the file.

Extended reasoning...

Small, self-contained fix (111 insertions, 2 deletions) adding a try/catch wrapper around chain-sdk's generateManifest to convert a raw thrown Error into a structured ValidationError; no auth, crypto, or data-exposure surface is touched. No prior findings and no third-party review comments to address. Verified the new instancePath and "Invalid SDL: ..." message format match existing patterns elsewhere in sdl.service.ts and deployment-writer.service.ts, and that tests follow the repo's setup() convention.

@baktun14

Copy link
Copy Markdown
Contributor Author

Matches the change: the catch is limited to the Invalid size string: prefix and everything else still throws, with unit, service and functional coverage. Nothing to change.

@baktun14
baktun14 added this pull request to the merge queue Sep 24, 2026
Merged via the queue into main with commit 6903b3b Sep 24, 2026
59 checks passed
@baktun14
baktun14 deleted the fix/sdl-reject-size-without-unit branch September 24, 2026 18:12
@baktun14

Copy link
Copy Markdown
Contributor Author

Upstream fix opened: akash-network/chain-sdk#362 makes the TS SDL parser accept a bare byte count the way the Go parser already does, with a parity fixture. Once that ships in a chain-sdk release and Console bumps, this 400 path becomes unreachable for bare numbers and can be dropped.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant