Reset Fern Replay so the v4 SDK generates clean - #338
Merged
Conversation
Unfreezing .fernignore was not enough. Fern Replay records each generation's tree hash in .fern/replay.lock and re-applies everything that has diverged since as a customization, independent of .fernignore. The lock on this branch is v3's history, so every v3 hand-written file still looked like a customization and came back on top of the generated v4 client -- the last generation failed mypy on a client.py that Replay had restored. Removes the lock so v4 starts with no recorded customizations, and stops freezing it: the file is Fern's own state, and pinning it is what made the history outlive the line it described. Anything worth carrying forward from v3 is re-added deliberately, which Replay will then track from a v4 baseline.
The earlier port rewrote client.py, external_clients, graph/utils.py and their tests against v4 type names, while the checked-in generated code is still v3's. The branch could not typecheck, so nothing on it could be verified, and the port itself is now moot: these files are unfrozen and Replay is reset, so the next generation writes them. Restores them to the v3 state the branch was cut from. Unlike Go, they cannot simply be deleted: __init__.py is generated and imports client.py, so removing it breaks the package before a generation can replace it. The Pydantic ontology DSL is the one piece here Fern will not regenerate. It stays in history and is re-added deliberately if it earns its place on v4.
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
1 participant
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.
Unfreezing
.fernignorewas not enough.Fern Replay records each generation's tree hash in
.fern/replay.lockand re-applies everything that has diverged since as a customization — independently of.fernignore. The lock on this branch is v3's history, so every v3 hand-written file still read as a customization and was re-applied on top of the generated v4 client.Evidence: the last generation PR (#337) carries a
[fern-replay] Applied customizationscommit that restoredsrc/zep_cloud/client.py, and mypy then failed on it.This removes the lock so v4 starts with no recorded customizations, and stops freezing it — it is Fern's own state, and pinning it is what let a v3 history outlive the line it described.
No CI change is needed here: this repo's failure was Replay, not the workflow.