fix(sdk): expose the flat-files surface on the TypeScript HistoricalClient#865
Merged
Conversation
…lient The standalone HistoricalClient documents a historical / list / snapshot / at-time / flat-files surface identical to the unified client, but the flatFiles getter and flatFileToPath writer were implemented only on the unified Client. A historical-only handle therefore resolved flatFiles to undefined at runtime, breaking the contract its own docstring promises and diverging from the Python HistoricalClient, which delegates to its wrapped client and reaches the flat-files surface. The historical-only handle opens the same data channel and holds the same client core, so the namespace and the to-path writer are client-agnostic. Mirror both members onto HistoricalClient so the documented surface is reachable, matching the unified client and the Python binding. The structural contract test now pins the flat-files surface on HistoricalClient against the unified Client. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The standalone
HistoricalClientdocuments a historical / list / snapshot / at-time / flat-files surface identical to the unified client, but theflatFilesgetter andflatFileToPathwriter were implemented only on the unifiedClient. A historical-only handle therefore resolvedflatFilestoundefinedat runtime, breaking the contract its own docstring promises and diverging from the PythonHistoricalClient, which delegates to its wrapped client and reaches the flat-files surface.The invariant:
HistoricalClientexposes the flat-files surface its contract promises, matching the Python binding and the unified client.The historical-only handle opens the same data channel and holds the same client core, so the
FlatFilesNamespaceand the to-path writer are client-agnostic. Both members are mirrored ontoHistoricalClientso the documented surface is reachable. The regeneratedindex.d.tsnow declaresget flatFiles()andflatFileToPathon the class, and the structural contract test pins the flat-files surface onHistoricalClientagainst the unifiedClient.Verification:
cargo checkandcargo fmt --all -- --checkclean;npm run buildregeneratesindex.d.tswith the new members;npm testpasses (170/170); the binding parity gate is clean with no new row required.🤖 Generated with Claude Code