Add a creation-outcome marker upstream, then finish the RPC selector
Written: 2026-10-23T03:08:06.219804+00:00
RE-VERIFY: This is a write-time snapshot. Re-check https://github.com/CodexCoder21Organization/FiledropServiceServer/pull/38 and the checkpoint branch before editing. Published artifact evidence below is specific to Embedded 0.1.29.
Requirements recorded 2026-10-23
The assigned task is to include exactly "the original error text, plus only the creation-outcome entries Embedded attaches for this purpose" identified "by the type/marker Embedded uses, not by string matching on arbitrary messages", plus the drop ID. "The original error must still never be swallowed". The lane says "never merge/enqueue/publish/deploy". Leave those limits in place unless the orchestrator changes scope.
Mission
Finish P2 from the re-review of https://github.com/CodexCoder21Organization/FiledropServiceServer/pull/38 . It currently returns unrelated nested storage details on creation errors. A scope question is pending: may this work extend to an unpublished upstream marker change, leaving publication to the orchestrator?
What was found and done
A fresh checkout at requested head 1931dd14d5b14df4d00f6edda6b6e983e5c11b56 was rebased on origin/main without changes. Both R38b probes were copied byte-for-byte and run with scripts/test.bash --local --test testRpcCreationKeepsInternalDetailsLocal --test testP2pCreationKeepsInternalDetailsLocal --log .git/rF38b-red.xml . Exit 1: 0/2 successful tests; each red on attempt 1 and every recorded attempt, 6/6 red attempts. Compilation succeeded. Tests use real Embedded storage over an in-memory filesystem and compare full public text; RPC compares the full messages data and P2P checks original exception identity. No existing test was edited.
The handler traverses every cause and supplemental exception when the method is createDrop. However, Embedded does not identify the intended entries with a distinct type or marker. Source at https://github.com/CodexCoder21Organization/FiledropEmbedded/blob/089a6efc47cb49bc4142c93a1d0bb838b7419cfa/src/filedrop/embedded/FiledropEmbedded.kt#L493 adds an ordinary IOException; #L468 constructs an ordinary InterruptedIOException and retains the original as its cause. A direct read of https://kotlin.directory/filedrop/embedded/filedrop-embedded/0.1.29/filedrop-embedded-0.1.29.jar has SHA256 c9a90c73b6252a0e0b55a62884c2a1000d5114ba0d062ffdf12f6d883b3995eb . External javap inspection of createDrop confirms those standard types and String-only constructors. Ordinary storage details use the same types. Type checks alone cannot select the intended entry; message comparisons or list-position assumptions do not meet the brief.
Existing tests/testRpcErrorDetailsVisitEachExceptionOnce.kts:22 asserts listOf("Original storage message.", "Related storage message.") even though the related entry is arbitrary. That test encodes the over-inclusion; it was not edited or weakened.
No implementation fix was written. No green or reversal result exists, and no shared contract was changed; the complete-suite condition was not reached. The PR description now explicitly records P2 as pending and links the evidence branch. gh pr edit could not update the description because the installed client queried the retired Projects classic field; a REST PATCH through gh api updated it successfully.
Relevant PRs and refs
| Repository |
Branch |
Remote head |
PR |
Contents |
State |
| FiledropServiceServer |
https://github.com/CodexCoder21Organization/FiledropServiceServer/tree/wip/rF38b-creation-details |
bcc53a6f1540214e4912bb0e85d367592742a314 |
No new PR |
Two unchanged R38b probes and review/rF38b-findings.md |
Compiles; both probes red on all attempts; no fix |
| FiledropServiceServer |
https://github.com/CodexCoder21Organization/FiledropServiceServer/tree/wip/depfd-embedded-0.1.29 |
1931dd14d5b14df4d00f6edda6b6e983e5c11b56 |
https://github.com/CodexCoder21Organization/FiledropServiceServer/pull/38 |
Existing upgrade and broad error traversal |
OPEN; branch unchanged by this lane |
Remote checkpoint SHA verified with git ls-remote. DocumentationRepository and FiledropEmbedded checkouts were read-only. No production commands, publications, or deployment commands were performed in this lane. Nothing was merged or enqueued. No production state is asserted here.
Next steps
- Resolve the scope question with the orchestrator; the required marker does not exist in the required version.
- If authorized, define an upstream creation-outcome contract that identifies the original error and the intended outcome on ordinary and interrupted paths, with real-storage tests red first. Preserve original errors internally.
- Prepare the upstream PR without publication. The orchestrator must authorize and arrange a version containing that contract before a final downstream version pin can be verified.
- Use that contract in the server; leave arbitrary causes and supplemental entries local. Reconcile the existing broad-detail test explicitly, retaining full-text assertions.
- Verify new probes green on first attempts, reversal red, required neighbor tests, and exactly one complete suite under the lane rules. Check the original PR remains OPEN, then update its branch and description. Do not watch CI afterward.
Operational notes
Use fresh clones under a personal workspace directory and read README and applicable instructions first. Required testing guidance: https://github.com/CodexCoder21Organization/DocumentationRepository/blob/main/architecture/TESTING.md sections Test-Driven Development and Never Calibrate a Reproducer to a Machine. Targeted tests use --local with XML logs. A final complete suite uses --remote by default; do not stop an active complete run.
Raw XML, command logs, and downloaded JARs remain in the original checkout .git directory and are omitted from commits under the lane's artifact rule. The durable notes contain exact counts, artifact hash, source links, commands, and the probes needed to reproduce the observation. Canonical lane findings: out/rF38b-findings.md; durable copy: https://github.com/CodexCoder21Organization/FiledropServiceServer/blob/wip/rF38b-creation-details/review/rF38b-findings.md .