DEV Community: Akshit Singh

@Cron fires on every replica. I found out the boring way

Akshit Singh — Thu, 24 Sep 2026 23:15:00 +0000

How an in-process scheduler turned one nightly job into N duplicate writes, and why I moved scheduling out of the app entirely.

I was looking at staging data when I found two of something that should only ever exist once: two identical records for the same entity, same start date, created seconds apart. Not corrupted, not half-written. Just two, where there should have been one.

The job that creates those records runs once a night. So why did it run twice?

Because we run more than one copy of the service, and the scheduler lived inside the service.

The setup

A nightly job rolls every active entity forward into its next bounded time-window — one new record each, once a day. Standard NestJS:

@Injectable()
export class WindowGenerationService {
  @Cron('0 8 * * *') // every day at 08:00
  async generateNextWindows() {
    const entities = await this.repo.findActiveEndingSoon();
    for (const entity of entities) {
      await this.repo.createNextWindow(entity);
    }
  }
}

This is the documented way to schedule work in NestJS. It's what you reach for. It worked perfectly the entire time we ran a single instance.

Then we scaled horizontally. Now there are three instances. @Cron doesn't know that. The decorator schedules the job in every process that boots it. Three instances, three timers, three simultaneous runs at 08:00 — and because there was no idempotency check and no lock, all three sailed past "does this already exist?" and each wrote its own copy.

Two things bothered me equally. One, duplicate data. Two, I was paying three containers to do the same work at the same time and then paying again to clean up the mess. The scheduler being in-process wasn't just a correctness bug, it was wasted compute by design.

What I considered

Option 1: a distributed lock. Keep @Cron, but have instances race for a lock — an advisory lock, or a key in a cache — and let the winner run. It works, and it trades a loud failure for a silent one. Duplicate writes are at least visible; you can find them and delete them. A missed run isn't: if the lock backend is down at 08:00, or an instance dies holding the lock and the TTL hasn't expired, the job just doesn't fire, and nobody notices until someone's window is missing days later. I'd be adding a whole new dependency, and a new way to fail quietly, to fix a problem I'd created by putting the timer in the wrong place.

Option 2: idempotency only. Add a check so a second run is a no-op. Cheap, correct, but it still wakes up three containers to do redundant work every night.

Option 3: take scheduling out of the app. The app shouldn't own when. Let an external scheduler own the clock and fire a single HTTP request at a normal endpoint. The app only owns what happens when it's poked. One trigger, one run, and horizontal scaling stops multiplying anything.

I went with 3, and kept the idempotency from 2 as a seatbelt.

The change

The @Cron decorator went away. The logic moved behind an endpoint:

@Post('jobs/run')
async runJob(@Body() body: RunJobDto) {
  this.assertValidSecret(body.secret);
  return this.jobs.run(body.jobKey);
}

An external scheduler fires this once at 08:00. The instance that receives it runs the job; the other two never hear about it.

The idempotency check stayed, because "fires once" is a promise infrastructure makes and occasionally breaks — retries, manual re-triggers, a restart mid-run:

async createNextWindow(entity: Entity) {
  const existing = await this.repo.findByEntityIdAndStartDate(
    entity.id,
    entity.nextStartDate,
  );
  if (existing) return; // already done, no-op
  await this.repo.create(/* ... */);
}

What it cost

The moment you turn a private nightly job into an HTTP endpoint, you've created a public button that runs a job. Anyone who finds it can hammer it. So the endpoint is guarded by a shared secret — and the comparison matters more than people expect:

private assertValidSecret(provided: string) {
  const expected = this.config.cronSecret;
  const a = Buffer.from(provided);
  const b = Buffer.from(expected);
  if (a.length !== b.length || !timingSafeEqual(a, b)) {
    throw new UnauthorizedException();
  }
}

A naive provided === expected leaks information through how long it takes to fail — a timing oracle you can walk character by character. timingSafeEqual compares in constant time. It's a small thing that reviewers usually don't flag; I'd rather not gamble that the endpoint stays undiscovered.

The other cost was dumber: picking the hour. The job has to run after everyone's start of the day, and "everyone" spans several US time zones — a time that's mid-morning in the east is pre-dawn out west. So the schedule is pinned to a fixed UTC hour chosen against the westernmost operating timezone, because that's the one that makes it safe everywhere. UTC in the crontab, human timezones in the requirement — the gap between those two is where the real decision lives.

The lesson

An in-process scheduler is a lie the moment you run more than one instance — it quietly multiplies by your replica count, and nothing in the code hints at it. Scheduling is a "when" concern, and it belongs outside the app; the app should only own "what happens." And the instant you expose a job as an endpoint to get there, it's a public endpoint — treat it like one, and keep the idempotency check anyway, because "it only fires once" is someone else's promise.

Why Laravel’s bcrypt Hashes Fail in Node.js and How to Fix It

Akshit Singh — Sun, 08 Jun 2025 09:40:15 +0000

Introduction

When integrating a new Node.js authentication service with an existing Laravel-based database, you may encounter failed password comparisons despite entering the correct credentials. This issue arises from a subtle difference in bcrypt hash prefixes between PHP and Node.js implementations. Understanding and addressing this discrepancy is essential for a seamless migration and secure user experience.

Background: bcrypt Prefix Variants

Bcrypt hashes include a three-character prefix that indicates the algorithm version and implementation details:

$2a$ : Original bcrypt specification.
$2b$ : Revision addressing 8-bit character handling.
$2y$ : PHP’s prefix, introduced after CVE-2011-2483, to distinguish patched implementations.

While the underlying hashing algorithm for $2y$ and $2b$ is identical, most Node.js libraries (e.g., bcrypt, bcryptjs) only recognize $2a$ and $2b$ . As a result, hashes beginning with $2y$ are treated as invalid and comparisons will fail.

Problem Demonstration

import bcrypt from 'bcryptjs';

const storedHash = '$2y$10$PszNdKUcfTXs9VE/9iB2meaqZt0vx5cE.LZP2v6A3F6N1Uz9yEHE6';
const password    = 'correctHorseBatteryStaple';

bcrypt.compare(password, storedHash)
  .then(isMatch => {
    console.log(isMatch ? 'Authenticated' : 'Invalid credentials');
  })
  .catch(error => {
    console.error('Error during comparison:', error);
  });

Output:

Invalid credentials

Despite providing the valid password, bcrypt.compare() fails because the hash prefix $2y$ is not recognized.

Solution: Normalizing the Prefix

Convert the PHP-specific $2y$ prefix to $2b$ before invoking bcrypt.compare(). This approach preserves the original hash content and maintains security.

function normalizeBcryptHash(hash) {
  return hash.startsWith('$2y$')
    ? '$2b$' + hash.slice(4)
    : hash;
}

async function verifyPassword(plainPassword, storedHash) {
  const compatibleHash = normalizeBcryptHash(storedHash);
  return await bcrypt.compare(plainPassword, compatibleHash);
}

// Usage example
const result = await verifyPassword(password, storedHash);
console.log(result ? 'Authenticated' : 'Invalid credentials');

By ensuring the prefix is $2b$ , the Node.js bcrypt library correctly processes the hash.

Best Practices for New Passwords

Generate All New Hashes in Node.js When registering new users or updating passwords, use the Node.js bcrypt implementation directly. It will produce hashes with the standard $2b$ prefix:

   const saltRounds = 10;
   const newHash     = await bcrypt.hash('newPassword', saltRounds);
   // newHash will begin with '$2b$'

Gradual Prefix Migration Retain the prefix-normalization logic in your login flow. As users authenticate or change their passwords, the system will automatically replace outdated $2y$ hashes with $2b$ , phasing out the legacy prefix without user interruption.

Security Considerations

Algorithm Integrity: Changing the prefix does not weaken the hash; bcrypt’s strength derives from its salt rounds.
User Experience: No forced password resets are necessary; users continue logging in with existing credentials.
Maintainability: Centralizing the prefix normalization in a utility function simplifies future maintenance.

Conclusion

A three-character prefix can disrupt cross-platform bcrypt compatibility, but the resolution is straightforward. By normalizing $2y$ to $2b$ , you ensure seamless password verification between a Laravel-generated database and a Node.js authentication service. Implementing this fix and generating all new hashes in Node.js will result in a consistent, secure, and maintainable authentication system.