Skip to content

refactor: unify duplicate execution paths in executor#2

Merged
simonovic86 merged 5 commits intomainfrom
claude/xenodochial-taussig
Mar 10, 2026
Merged

refactor: unify duplicate execution paths in executor#2
simonovic86 merged 5 commits intomainfrom
claude/xenodochial-taussig

Conversation

@simonovic86
Copy link
Owner

Summary

  • Merged execute() and executeClaimedCommand() into a single execute(instance, claimed bool) method — the claimed bool controls the 3 points where queue-mode and polling-mode behavior diverges
  • Merged safeExecute() and safeExecuteClaimed() similarly
  • Added scheduleFn function field set in Start() — no-op in polling mode, queueSchedule in queue mode — replacing the dead schedule() code path
  • Simplified recoverStuckCommands() to use scheduleFn instead of manual LockingStorage type assertion
  • Applied gofmt -s to CLI command files

Net: ~100 lines removed from executor.go, zero behavior change, all tests pass with race detector.

Test plan

  • go build ./... succeeds
  • go test -race ./... — all tests pass (38s main, 5s storage)
  • Manual verification that polling mode (Postgres) still works end-to-end

🤖 Generated with Claude Code

simonovic86 and others added 3 commits March 10, 2026 15:21
Eliminate ~90% code duplication between queue-based and polling-based
execution modes by:

- Merging execute() and executeClaimedCommand() into execute(instance, claimed bool)
  with 2 small guards at the 3 points where behavior diverges
- Merging safeExecute() and safeExecuteClaimed() into safeExecute(instance, claimed bool)
- Adding scheduleFn function field (set in Start()) that is a no-op in
  polling mode, making the dead code path explicit instead of accidental
- Renaming schedule() to queueSchedule() for clarity
- Simplifying recoverStuckCommands() to use scheduleFn instead of manual
  LockingStorage type assertion

Net: ~100 lines removed, single execution path, zero behavior change.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Change `durex` to `/durex` so only the root-level binary is ignored,
not the `cmd/durex/` directory.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
@simonovic86 simonovic86 force-pushed the claude/xenodochial-taussig branch from 92d4146 to 8f12b27 Compare March 10, 2026 14:21
Copy link

@chatgpt-codex-connector chatgpt-codex-connector bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: b711f55139

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".


// Schedule for execution
e.schedule(instance)
e.scheduleFn(instance)

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Badge Initialize scheduleFn before replaying DLQ commands

ReplayFromDLQ now invokes e.scheduleFn(instance) directly, but scheduleFn is only assigned inside Start() (see executor.go initialization in Start), so calling this public API before the executor is started will panic with a nil function call; before this refactor, schedule() was always callable and did not crash in that scenario. This affects DLQ admin flows that replay commands while the worker loop is not yet running.

Useful? React with 👍 / 👎.

simonovic86 and others added 2 commits March 10, 2026 15:27
The `buildir` checker doesn't exist in golangci-lint's govet settings,
causing CI to fail with "the configuration contains invalid elements".

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
- Remove ineffectual argNum++ after last query condition in postgres Find()
- Initialize scheduleFn to no-op in New() so it's never nil before Start()

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
@simonovic86
Copy link
Owner Author

Addressed review feedback in 098b4eb:

  • Lint fix: Removed ineffectual argNum++ in storage/postgres.go:522
  • Nil scheduleFn panic: scheduleFn is now initialized to a no-op in New(), so calling ReplayFromDLQ or any other scheduleFn user before Start() won't panic

@simonovic86 simonovic86 merged commit 4576672 into main Mar 10, 2026
3 checks passed
@simonovic86 simonovic86 deleted the claude/xenodochial-taussig branch March 10, 2026 14:33
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant