Skip to content

Fix/soc chunk detection#5445

Open
significance wants to merge 2 commits intoethersphere:masterfrom
significance:fix/soc-chunk-detection
Open

Fix/soc chunk detection#5445
significance wants to merge 2 commits intoethersphere:masterfrom
significance:fix/soc-chunk-detection

Conversation

@significance
Copy link
Copy Markdown
Member

Checklist

  • I have read the coding guide.
  • My change requires a documentation update, and I have done it.
  • I have added tests to cover my changes.
  • I have filled out the description and linked the related issues.

Description

The POST /chunks handler tries CAC (Content Addressed Chunk) parsing before SOC (Single Owner Chunk) parsing. Since CAC parsing accepts any data between 8-4104 bytes, valid SOC data is always misclassified as CAC and stored at the wrong content-addressed hash instead of the correct SOC address (Hash(Identifier || Owner)).

This breaks client-side SOC construction workflows where pre-stamped SOCs are uploaded via POST /chunks — the chunk is stored but can never be retrieved at its expected SOC address.

The fix reverses the detection order: try SOC parsing first, fall back to CAC.

Open API Spec Version Changes (if applicable)

N/A — no API contract change, only fixes incorrect internal routing of chunk types.

Motivation and Context

Client-side SOC construction (e.g. using bee-js makeContentAddressedChunk().toSingleOwnerChunk() then uploadChunk()) relies on POST /chunks correctly identifying and storing SOCs at their SOC address. Without this fix, all SOCs uploaded via this endpoint are silently stored as CACs at the wrong address.

Related Issue

N/A

Screenshots (if appropriate):

N/A

AI Disclosure

  • This PR contains code that has been generated by an LLM.
  • I have reviewed the AI generated code thoroughly.
  • I possess the technical expertise to responsibly review the code generated in this PR.

SOC chunks uploaded via the generic /chunks endpoint are misclassified
as CAC chunks because the handler tries CAC parsing first, which always
succeeds for valid SOC data (8-4104 bytes). These tests demonstrate that
SOC uploads return incorrect addresses and are unretrievable.
Try SOC parsing before CAC in the chunk upload handler. CAC parsing
accepts any data between 8-4104 bytes, so valid SOC data was always
misclassified as CAC and stored at the wrong content-addressed hash
instead of the correct SOC address (Hash(Identifier || Owner)).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant