Conversation
What was broken The previous PM-4680 fix hid the editable task timeline inside ChallengeEditorForm, but task identity still fell back to unresolved type metadata and the page treated every existing challenge as edit mode. QA still saw timelines in task edit mode, and task view routes could also be misclassified as edit mode. Root cause ChallengeEditorPage passed isEditMode for every existing challenge instead of only the edit route. Inside ChallengeEditorForm, the task-only UI relied on resolved challenge type metadata and could overwrite a persisted task flag before that metadata was available. What was changed ChallengeEditorPage now passes edit mode only on true edit routes. ChallengeEditorForm now derives a single task-state flag from resolved type metadata plus the persisted task marker, uses that flag to hide the editable timeline in task edit mode, keeps task-only controls aligned with the same fallback, and preserves the persisted task flag until type metadata resolves. Any added/updated tests Updated ChallengeEditorPage.spec.tsx to cover edit-versus-view mode wiring into the details form. Updated ChallengeEditorForm.spec.tsx to cover the persisted task-flag fallback when challenge type metadata is unavailable in edit mode.
![devin-ai-integration[bot]](https://avatars.githubusercontent.com/in/811515?s=60&v=4){kind=small}
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
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.
What was broken
The previous PM-4680 fix hid the editable task timeline inside ChallengeEditorForm, but task identity still fell back to unresolved type metadata and the page treated every existing challenge as edit mode. QA still saw timelines in task edit mode, and task view routes could also be misclassified as edit mode.
Root cause
ChallengeEditorPage passed isEditMode for every existing challenge instead of only the edit route. Inside ChallengeEditorForm, the task-only UI relied on resolved challenge type metadata and could overwrite a persisted task flag before that metadata was available.
What was changed
ChallengeEditorPage now passes edit mode only on true edit routes. ChallengeEditorForm now derives a single task-state flag from resolved type metadata plus the persisted task marker, uses that flag to hide the editable timeline in task edit mode, keeps task-only controls aligned with the same fallback, and preserves the persisted task flag until type metadata resolves.
Any added/updated tests
Updated ChallengeEditorPage.spec.tsx to cover edit-versus-view mode wiring into the details form. Updated ChallengeEditorForm.spec.tsx to cover the persisted task-flag fallback when challenge type metadata is unavailable in edit mode. Repo-wide yarn test:no-watch still fails in the pre-existing wallet-admin PaymentsListView suite, and the same three failures reproduce on untouched origin/dev.