Reviewing files that changed from the base of the PR and between a10e2a8 and 0d4064e.

• .github/workflows/publish.yml (1 hunks)
• apps/webapp/app/env.server.ts (2 hunks)
• apps/webapp/app/v3/runEngine.server.ts (1 hunks)
• internal-packages/run-engine/src/engine/index.ts (1 hunks)
• internal-packages/run-engine/src/run-queue/index.ts (1 hunks)
• internal-packages/run-engine/src/run-queue/tests/nack.test.ts (1 hunks)
• internal-packages/testcontainers/src/index.ts (3 hunks)

• GitHub Check: e2e / 🧪 CLI v3 tests (windows-latest - pnpm)
• GitHub Check: e2e / 🧪 CLI v3 tests (windows-latest - npm)
• GitHub Check: e2e / 🧪 CLI v3 tests (ubuntu-latest - pnpm)
• GitHub Check: e2e / 🧪 CLI v3 tests (ubuntu-latest - npm)
• GitHub Check: units / 🧪 Unit Tests
• GitHub Check: typecheck / typecheck
• GitHub Check: Analyze (javascript-typescript)

internal-packages/testcontainers/src/index.ts (3)

56-58: Good improvement to container management reliability

Adding a timeout to the container stop operation ensures that the function waits until the container has fully terminated before proceeding. This prevents potential test flakiness that could occur if subsequent tests try to reuse resources before they're fully released.

---

97-99: Consistent approach to container termination

The same timeout pattern is correctly applied to Redis containers, maintaining consistency across different container types and ensuring reliable cleanup during tests.

---

149-151: Clear documentation with implementation

The detailed comments explaining why the timeout is necessary are valuable. They help future developers understand the rationale behind these changes and prevent them from being accidentally removed.

apps/webapp/app/v3/runEngine.server.ts (1)

98-98: Correctly propagating retry threshold configuration

This change addresses one of the root causes mentioned in the PR objectives - ensuring that the retryWarmStartThresholdMs parameter is properly passed through the system. This value controls when retries should use warm starts, which is critical for preventing duplicate attempt spans.

apps/webapp/app/env.server.ts (1)

463-463: Good default value for retry warm start threshold

Setting a default of 30 seconds for the retry warm start threshold provides a reasonable balance. It's long enough to handle most typical processing delays while not being so long that it would significantly impact user experience for retriable operations.

internal-packages/run-engine/src/engine/index.ts (1)

307-307:

✅ Verification successful

Completing the configuration chain for warm start threshold

This change completes the propagation of the retryWarmStartThresholdMs configuration from environment variables through to the RunAttemptSystem where it will be used to determine whether to use warm starts for retries. This addresses one of the key issues mentioned in the PR objectives.

Consider verifying that the RunAttemptSystem constructor properly accepts and utilizes this parameter with:

---

🏁 Script executed:

#!/bin/bash
# Confirm that RunAttemptSystem accepts the retryWarmStartThresholdMs parameter
fd RunAttemptSystem.ts --type f | xargs cat | grep -A 20 "constructor"

Length of output: 70

---

🏁 Script executed:

#!/bin/bash
# Locate the TypeScript file defining RunAttemptSystem
file=$(rg --files-with-matches "class RunAttemptSystem" --glob "*.ts")
if [[ -z "$file" ]]; then
  echo "No file found containing RunAttemptSystem class"
  exit 1
fi

echo "Found in: $file"
echo
echo "=== class definition ==="
rg -n "class RunAttemptSystem" "$file"
echo
echo "=== constructor ==="
rg -n "constructor" "$file"

Length of output: 802

---

🏁 Script executed:

#!/bin/bash
# Locate and display the definition of RunAttemptSystemOptions
echo "=== RunAttemptSystemOptions Definition ==="
rg -n "interface RunAttemptSystemOptions" -A 20 --glob "*.ts"

echo
# Find all occurrences of retryWarmStartThresholdMs across the codebase
echo "=== Occurrences of retryWarmStartThresholdMs ==="
rg -n "retryWarmStartThresholdMs" --glob "*.ts"

Length of output: 1070

---

Propagated and Utilized: retryWarmStartThresholdMs Verified

– The RunAttemptSystemOptions interface (internal-packages/run-engine/src/engine/types.ts:43) declares retryWarmStartThresholdMs.
– The RunAttemptSystem constructor (internal-packages/run-engine/src/engine/systems/runAttemptSystem.ts:54) accepts these options.
– The retry logic in RunAttemptSystem (lines 710–711) correctly checks this.options.retryWarmStartThresholdMs when deciding on a warm start.

No further changes needed; this parameter is fully wired through and used as intended.

.github/workflows/publish.yml (2)

59-59: Appropriate dependency update to ensure unit tests pass before publishing

Adding the units job as a dependency ensures that unit tests must pass before the webapp is published, improving the reliability of deployments.

---

66-66: Appropriate dependency update to ensure unit tests pass before publishing

Adding the units job as a dependency ensures that unit tests must pass before the worker is published, improving the reliability of deployments.

internal-packages/run-engine/src/run-queue/index.ts (1)

544-544: Fixed retry timing respect in nackMessage

This change correctly passes the retryAt parameter to the #callNackMessage method, ensuring that when a message is nacked with a specific retry time, that timing is respected when re-queueing the message.

This directly addresses one of the root causes mentioned in the PR objectives: "the run queue's nackMessage method did not honor the retryAt timing for retries".

internal-packages/run-engine/src/run-queue/tests/nack.test.ts (1)

218-277: Good test coverage for the retryAt functionality

This test appropriately verifies that when a message is nacked with a specific retryAt timestamp, the message is requeued with the correct scheduled retry time. The test is thorough in:

1. Setting up the test environment with a Redis container
2. Enqueuing and dequeuing a message
3. Nacking it with a specific future timestamp
4. Verifying the queue timestamp matches the expected retry time

This ensures the fix for the retryAt parameter works as expected.