Repository navigation
Conversation
… status The Django side gains a waiting_for_domain status for a workflow that waits for its sender domain to verify. The node side only loads active workflows, so this change keeps the shared HogFlow type in step and changes no runtime behavior. It lands before the Django change so neither PR mixes lanes. Refs Silthus/personal#196 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This was referenced Oct 27, 2026
This branch has not been deployed
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
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.
Problem
"Send once verified" adds a
waiting_for_domainworkflow status: Enable saves it while the sender's email domain is unverified. #590 adds that status in Django and widened the nodeHogFlowschema in the same diff. Upstream rejects a PR that mixes Python andnodejs/changes, so #590 cannot land as it stands.Part of Silthus/personal#196. This PR lands before #590.
Note
🟢 Merge risk: low · two-way door (merge-risk rubric)
statusenum ofHogFlowSchema. No runtime code parses hog flows with this schema; it gives the sharedHogFlowtype.status='active'workflows, so a waiting workflow never reaches the worker. Nothing changes at runtime.Changes
HogFlowtype now acceptswaiting_for_domainas a status, so it matches every value Django can store. Mechanical; nothing a user sees changes.nodejs/change from feat(workflows): enable waits for an unverified sender and goes live once it verifies #590. Once this PR merges, feat(workflows): enable waits for an unverified sender and goes live once it verifies #590's diff againstmasterno longer contains it, and feat(workflows): enable waits for an unverified sender and goes live once it verifies #590 becomes a Python and frontend PR only.Production lines: 2 (+1 −1) by
git diff --numstatagainst the base branch.The base is
t3/workflows-sender-verification-refresh(#590's base), so the diff is that one line. The commit also applies cleanly on today'smaster.How did you test this code?
pnpm typescript:checkinnodejs/is clean, oxlint and eslint pass on the changed file, andsrc/cdp/schema/hogflow.test.tspasses.hogli ci:preflight --strictat push reported no failures.Test rationale: no new test. The schema gives a type only, and the node side never loads a waiting workflow, so no runtime behavior can regress. The typecheck is the seam: it fails if node code switches over
HogFlow['status']without the new value.Proofs (recorded with
fleet proof):Release status
The type change has no runtime effect. Only
workflows-email-domain-wizardmakes a workflow wait.Docs update
None.
🤖 Agent context
Autonomy: Human-driven (agent-assisted)
Agent: Claude Code, Opus 5.5 (
claude-opus-5-5)master.Involvement: one GPT-6.1 Sol review; lane gate captured.
🤖 Generated with Claude Code