Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

JEST_WORKER_ID starts with 0. #8204

Closed
dexterleng opened this issue Mar 24, 2019 · 5 comments · Fixed by #8205
Closed

JEST_WORKER_ID starts with 0. #8204

dexterleng opened this issue Mar 24, 2019 · 5 comments · Fixed by #8205

Comments

@dexterleng
Copy link

🐛 Bug Report

JEST_WORKER_ID starts from 0 instead of 1 specified here:

Note: Each worker has a unique id (index that starts with 1) which is available on process.env.JEST_WORKER_ID

https://github.com/facebook/jest/blob/master/packages/jest-worker/README.md

To Reproduce

Its on a private repo. I have tried reproducing it on a public repo but I couldn't get it to work.

I have two .spec.ts files with the same content:

import knex from "knex";
import { createTestConnection } from "../test-utils/createTestConnection";
import { clearDatabase } from "../test-utils/clearDatabase";

var testConnection: knex;
beforeAll(async (done) => {
  console.log(process.env.JEST_WORKER_ID);
  const connection = await createTestConnection(process.env.JEST_WORKER_ID);
  testConnection = connection;
  done();
});

afterEach(async (done) => {
  await clearDatabase(testConnection);
  done();
});

afterAll((done) => {
  testConnection.destroy(() => {
    done();
  });
});

test("quick maffs", async done => {
  expect(1 + 1).toEqual(2);
  done();
});

0 and 1 is printed.

Expected behavior

1 and 2 to be printed.

@dexterleng
Copy link
Author

Ok turns out I couldn't not reproduce because I was using CRA and react-scripts jest just is a bit behind ("23.6.0",). To reproduce just console.log(JEST_WORKER_ID) in any jest project.

@jeysal
Copy link
Contributor

jeysal commented Mar 24, 2019

Thanks for reporting, I'll take a look.

@natealcedo
Copy link
Contributor

natealcedo commented Mar 24, 2019

The way we instantiate workers now is different.

The original implementation assigned workers in a for loop and assigning id as i + 1.
https://github.com/facebook/jest/pull/5494/files#diff-61ba9f2c3304466545bec864a68f863d

Where as here we now have.
https://github.com/facebook/jest/blob/master/packages/jest-worker/src/base/BaseWorkerPool.ts#L41

I've tested this locally and this only occurs when the tests are ran in parallel.
Running tests in band correctly assigns the id to 1

Small regression that happened during the migration to typescript

@jeysal
Copy link
Contributor

jeysal commented Mar 24, 2019

Yes, I noticed that. This used to work (and still does for runInBand).
I first wanted to convert workerIds everywhere to 1-indexed, but that touches many places and is quite unintuitive. TBH I don't really understand why it was ever 1-indexed (especially given that the 0 is not used for in band runs as suggested in the original PR). I'll now just make process.env.JEST_WORKER_ID be workerId + 1 I guess.

jeysal added a commit that referenced this issue Mar 26, 2019
<!-- Thanks for submitting a pull request! Please provide enough information so that others can review your pull request. The two fields below are mandatory. -->

<!-- Please remember to update CHANGELOG.md in the root of the project if you have not done so. -->

## Summary

Fixes #8204 
It's weird that it's 1-indexed (I looked at making our `workerId` 1-indexed too for consistency, but that would make our code really weird), but I guess it's documented, used to work like that and still does for `runInBand` 🤷‍♂️ 
<!-- Explain the **motivation** for making this change. What existing problem does the pull request solve? -->

## Test plan

<!-- Demonstrate the code is solid. Example: The exact commands you ran and their output, screenshots / videos if the pull request changes UI. -->
@github-actions
Copy link

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.
Please note this issue tracker is not a help forum. We recommend using StackOverflow or our discord channel for questions.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators May 12, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants