Skip to content

fix: fips crashing#5580

Merged
varonix0 merged 3 commits intomainfrom
daniel/fix-fips-crash
Mar 4, 2026
Merged

fix: fips crashing#5580
varonix0 merged 3 commits intomainfrom
daniel/fix-fips-crash

Conversation

@varonix0
Copy link
Member

@varonix0 varonix0 commented Mar 4, 2026

Context

We have created new queues recently which didn't have FIPS-specific settings on it like our primary queue does. Adding this will force the queue to use the sha256 algorithm for hashing rather than md5. This does not affect non-fips instances.

Steps to verify the change

Type

  • Fix
  • Feature
  • Improvement
  • Breaking
  • Docs
  • Chore

Checklist

  • Title follows the conventional commit format: type(scope): short description (scope is optional, e.g., fix: prevent crash on sync or fix(api): handle null response).
  • Tested locally
  • Updated docs (if needed)
  • Read the contributing guide

@varonix0 varonix0 self-assigned this Mar 4, 2026
@varonix0 varonix0 requested a review from x032205 March 4, 2026 01:42
@maidul98
Copy link
Collaborator

maidul98 commented Mar 4, 2026 •
edited
Loading

✅ Snyk checks have passed. No issues have been found so far.

Status Scanner Critical High Medium Low Total (0)
✅ Open Source Security 0 0 0 0 0 issues

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.

@greptile-apps
Copy link
Contributor

greptile-apps bot commented Mar 4, 2026

Greptile Summary

This PR propagates the FIPS-required repeatKeyHashAlgorithm: "sha256" setting to two recently-added BullMQ queues (QueueInternalRecovery and QueueInternalReconciliation) that were previously missing it, preventing a crash on FIPS-enabled instances.

Critical Issue: The fix is incomplete. FIPS settings are correctly applied to the Queue instances, but the corresponding Worker instances created in the initialize() function are missing the same settings. The existing start() function correctly applies FIPS settings to both Queue and Worker, establishing the pattern that should be followed here.

In FIPS mode, BullMQ hashes repeat-job keys using the configured algorithm. A mismatch between producer (Queue) and consumer (Worker) — particularly for QueueInternalReconciliation, which schedules a repeatable cron job — can cause workers to fail to correctly resolve/process those jobs. This is a functional bug that must be fixed.

Confidence Score: 3/5

  • PR partially fixes FIPS crash risk for Queues but leaves corresponding Workers without required FIPS settings, risking hash-algorithm mismatch for repeatable jobs in FIPS mode.
  • The PR correctly identifies and partially fixes the FIPS issue by adding repeatKeyHashAlgorithm: "sha256" to new Queue instances. However, the fix is incomplete: the corresponding Worker instances in initialize() are missing the same FIPS settings. This creates a hash-algorithm mismatch in FIPS mode where the Queue uses sha256 but the Worker defaults to md5. This is particularly problematic for QueueInternalReconciliation, which schedules a repeatable cron job. The established pattern in the start() function shows that both Queue and Worker must be configured identically for FIPS. This is a functional bug that must be addressed before merge.
  • backend/src/queue/queue-service.ts — Worker instances in initialize() (lines 839–860) need to have fipsSettings spread into their options, matching the pattern in start().

Last reviewed commit: 51cbf52

@greptile-apps
Copy link
Contributor

greptile-apps bot commented Mar 4, 2026

Additional Comments (1)

backend/src/queue/queue-service.ts, line 860
FIPS settings missing on internal Workers

The fipsSettings are correctly applied to both Queue and Worker instances in the start() function (lines 906–942), but the initialize() function only applies them to the Queue instances — the corresponding Worker instances for QueueInternalRecovery and QueueInternalReconciliation are still created without the repeatKeyHashAlgorithm: "sha256" setting.

This is particularly relevant for QueueInternalReconciliation, which schedules a repeatable job (pattern "*/2 * * * *"). In FIPS mode, BullMQ hashes the repeat key using the configured algorithm. If the Queue uses sha256 but the Worker defaults to md5, the worker may fail to correctly resolve/process those repeatable jobs.

The fix should apply fipsSettings to both workers:

workerContainer[QueueName.QueueInternalRecovery] = new Worker(
  QueueName.QueueInternalRecovery,
  async () => {
    await startupRecovery();
  },
  {
    prefix: isClusterMode ? `{${QueueName.QueueInternalRecovery}}` : undefined,
    ...fipsSettings,
    connection
  }
);

// Start reconciliation worker
workerContainer[QueueName.QueueInternalReconciliation] = new Worker(
  QueueName.QueueInternalReconciliation,
  async () => {
    await runReconciliation();
  },
  {
    prefix: isClusterMode ? `{${QueueName.QueueInternalReconciliation}}` : undefined,
    ...fipsSettings,
    connection
  }
);

@varonix0 varonix0 merged commit 44d5df3 into main Mar 4, 2026
10 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@carlosmonastyrski carlosmonastyrski carlosmonastyrski approved these changes

@x032205 x032205 Awaiting requested review from x032205

Assignees

@varonix0 varonix0

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

3 participants

@varonix0 @maidul98 @carlosmonastyrski