Migration copy#1562
Conversation
…roject/mentoring into feature/int_test
…into feature/int_test
…into feature/int_test
…into feature/int_test
…into feature/int_test12
…into feature/int_test
…/mentoring into feature/int_test_1
…/mentoring into feature/int_test_1
…/mentoring into feature/int_test_1
…into migrations_update
…into migrations_update
WalkthroughA comprehensive integration test infrastructure expansion is introduced across 40+ new test files, alongside CI/CD pipeline enhancements for Citus database support and explicit health checks. Includes database schema distribution configuration updates, common test utilities with authentication helpers, JSON response schemas for API validation, and configuration adjustments for test execution and package management. Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Possibly related PRs
Suggested reviewers
🚥 Pre-merge checks | ✅ 1 | ❌ 2❌ Failed checks (1 warning, 1 inconclusive)
✅ Passed checks (1 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing touches
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 18
Note
Due to the large number of review comments, Critical severity comments were prioritized as inline comments.
🤖 Fix all issues with AI agents
In `@src/integration-tests-new/default-rule/schemas/default-rule.schemas.json`:
- Around line 35-37: Update the read schema in default-rule.schemas.json so the
item properties use "operator" (not "matching_operator") and
"requester_roles_config" (not "role_config") to match the database model and
service, and add appropriate "required" arrays to the read schema's item
properties to validate presence of expected fields; locate the read schema
section that defines the item object (where "matching_operator" and
"role_config" currently appear) and rename those keys to "operator" and
"requester_roles_config" and include a "required": [...] list containing the
required property names for that item.
In `@src/integration-tests-new/feedback/feedback.spec.js`:
- Line 15: Rename the test file or update Jest config so the integration tests
load the setup file and custom matcher; either rename feedback.spec.js to
feedback.specs.js (so it matches the existing integrationJest.config.js pattern)
or modify integrationJest.config.js testMatch to include **/*.spec*.js; ensure
the file using toMatchSchema remains named consistently and that
setupFileAfterEnv.js (which calls expect.extend(matchers)) is referenced by the
same config so the custom matcher toMatchSchema is registered at test runtime.
In `@src/integration-tests-new/mentees/mentees.specs.js`:
- Around line 10-11: The variable adminDetails is assigned without a declaration
causing an implicit global; change the assignment to declare it (e.g., use const
or let) and likewise declare adminToken; for example, replace the current lines
with a proper declaration like const adminDetails = await
commonHelper.adminLogin() and const adminToken = adminDetails.token or
destructure with const { token: adminToken } = await commonHelper.adminLogin()
so both variables are block-scoped.
- Line 105: The query string uses userDetails.id but the login helper (logIn)
returns userId, so userDetails.id will be undefined; update the test to
reference userDetails.userId (or destructure userId from the result of logIn())
wherever the mentorId is interpolated (the line building the url and any other
places using userDetails.id) so the correct userId is sent in the request.
- Line 114: The test constructs the request URL using the wrong property
userDetails.id; update the URL construction (the const url in the failing test)
to use userDetails.userId instead of userDetails.id so the mentorId query param
is set to the correct identifier; search for the const url declaration in the
mentees.specs.js test and replace the property reference accordingly.
In `@src/integration-tests-new/modules/modules.spec.js`:
- Line 35: The test is building URLs with the literal `{id}` token; update the
tests to capture the real module ID from the create response (e.g., use the
response body id from the "create module" test or a shared variable like
createdModuleId) and replace `{id}` when constructing the url for update and
delete requests (the occurrences that set url =
`/mentoring/v1/modules/update/{id}` and similar at the other two spots). Ensure
the update and delete tests use that captured id (e.g.,
`/mentoring/v1/modules/update/${createdModuleId}`) and apply the same
substitution pattern for the DELETE test and the other listed occurrences.
In `@src/integration-tests-new/org-admin/org-admin.spec.js`:
- Around line 7-23: The tests use placeholder auth headers ('x-auth-token' set
to 'string' or 'bearer {{token}}') so all requests will be rejected; update each
test that builds a request with request(BASE).post(url) (and other HTTP verbs)
to set a valid token by calling the shared test auth helper (e.g.,
getTestAuthToken() or similar) or reading a real test token from config/env
(e.g., process.env.TEST_AUTH_TOKEN) and then use req.set('x-auth-token', token)
instead of the literal 'string' so the test reaches the endpoint logic (also
ensure the helper is awaited if async and import/require it where tests
reference schemas like schemas['POST_mentoring_v1_org-admin_roleChange']).
In `@src/integration-tests-new/permissions/permissions.spec.js`:
- Around line 37-56: The test is calling the literal route string
"/mentoring/v1/permissions/update/{id}" instead of substituting a real
permission ID; update the test in permissions.spec.js so the POST to the update
endpoint uses a real id value (e.g., the ID returned by the create test or a
shared variable set in the create test) when building the URL used by
request(BASE).post(...); do the same fix for the delete test that currently
posts to "/mentoring/v1/permissions/delete/{id}" so both update and delete
requests target real resource IDs and then validate the responses against the
corresponding schemas (schemas['POST_mentoring_v1_permissions_update_id'] etc.).
In `@src/integration-tests-new/report-mapping/report-mapping.spec.js`:
- Around line 1-78: The tests use a placeholder header value 'bearer {{token}}'
and lack the shared auth setup, so success-path requests will 401; import the
common test auth helper (same pattern used in questions.spec.js /
role-extension.spec.js), add a beforeAll that obtains a real token (e.g., const
authToken = await commonHelper.login() or commonHelper.getAuthToken()) and
replace all req.set('x-auth-token', 'bearer {{token}}') occurrences with
req.set('x-auth-token', `bearer ${authToken}`) (or use a shared helper to set
headers) in the describe blocks for POST /create, GET /read, POST /update,
DELETE /delete to ensure valid authentication.
In `@src/integration-tests-new/report-queries/report-queries.spec.js`:
- Line 10: Replace the Postman template string being sent as the auth header by
calling the existing helper to obtain a real admin token: use
commonHelper.adminLogin() (or the same helper used in other suites) to get the
token, then set the header on the request object (the req variable where
req.set('x-auth-token', 'bearer {{token}}') appears) to `Bearer <actualToken>`
before sending; update every occurrence in this spec (the requests at the places
where req.set is used) to use the returned token rather than the literal
`'bearer {{token}}'`.
In `@src/integration-tests-new/report-type/report-type.spec.js`:
- Line 10: Replace the Postman placeholder string passed to the request header
with the real test token variable: wherever the test sets req =
req.set('x-auth-token', 'bearer {{token}}') (lines involving the req variable in
report-type.spec.js), change it to use the shared TOKEN variable (e.g.,
req.set('x-auth-token', `bearer ${TOKEN}`)) after TOKEN is properly initialized
so authentication uses the actual token; apply the same replacement for all
occurrences (the three places noted).
- Around line 1-4: Tests reference TOKEN and call toMatchSchema but TOKEN is
never declared and jest-json-schema isn't extended; fix by acquiring a real auth
token the same way as other tests (e.g., replicate the login/auth flow used in
admin.spec.js or commonTests.js and assign it to a top-level TOKEN variable
before tests run), and enable JSON schema matcher by calling
expect.extend(require('jest-json-schema').toMatchSchema) (or ensure your shared
test setup does this) so toMatchSchema works; update references in this file
(TOKEN usage in the test cases) to use the obtained TOKEN.
In `@src/integration-tests-new/reports/reports.spec.js`:
- Line 10: Replace the hardcoded header value 'bearer {{token}}' used on the req
object with a real token fetched at runtime: call your shared authentication
helper (e.g., getAuthToken() / authHelper.getToken()) or read from an env var
(e.g., process.env.TEST_AUTH_TOKEN), ensure the value is prefixed with the
proper "Bearer " casing, and set req.set('x-auth-token', `Bearer ${token}`) so
authenticated tests send a valid token instead of the literal placeholder.
In `@src/integration-tests-new/requestSessions/requestSessions.specs.js`:
- Line 50: The org-id header is being set with the whole object at the two
mentee sites; in
src/integration-tests-new/requestSessions/requestSessions.specs.js replace the
incorrect uses of menteeDetails.organizations[0] when building the request
header with the actual org id string by accessing the id property and converting
to string (use menteeDetails.organizations[0].id.toString()); update both
occurrences that call .set('org-id', menteeDetails.organizations[0]) so they
match the correct pattern used for mentorDetails.organizations[0].id.toString().
In `@src/integration-tests-new/role-extension/role-extension.spec.js`:
- Around line 1-104: The tests in role-extension.spec.js use
placeholder/undefined auth tokens (e.g., 'bearer {{token}}', 'test-token',
TOKEN) so authenticated requests will fail; fix by importing and using your test
login helper (e.g., commonHelper.getAuthToken or commonHelper.login) in a
beforeAll to obtain a real token, store it in a module-level TOKEN variable,
then replace the literal headers (instances of 'bearer {{token}}', 'test-token',
and the undefined TOKEN usage) with req.set('x-auth-token', TOKEN) (or the
correct header name/value your helper returns); also remove duplicate
req.set('x-auth-token', ...) calls where present (see usages in POST /create,
POST /update, GET /read, DELETE /delete and the top-level TOKEN reference) so
each request uses the real token from beforeAll.
- Around line 89-91: The test references TOKEN which is not declared, causing a
ReferenceError; fix by importing the login helper (e.g., commonHelper) and
obtaining an auth token in the test suite setup (beforeAll) and store it in a
variable used by this test; update the delete request code that uses
request(BASE).delete(url) to set the header with that token variable (replace
TOKEN with the setup token variable), ensuring the token is available to the
test that calls req.set('x-auth-token', ...).
In
`@src/integration-tests-new/rolePermissionMapping/rolePermissionMapping.spec.js`:
- Line 8: The URL string uses the literal "{role_id}" instead of substituting
the actual role id; change the const url assignments (e.g., const url =
`/mentoring/v1/rolePermissionMapping/create/{role_id}`) to interpolate the real
role id (for example `const url =
\`/mentoring/v1/rolePermissionMapping/create/${roleId}\``) using the role id
produced by your test setup (e.g., createdRole.id or a roleId variable), and
make the same replacement for the other occurrences so the requests target the
real route and ensure the roleId variable is initialized before the URL is
built.
- Line 37: The tests reference TOKEN (used in req.set('x-auth-token', TOKEN))
but TOKEN is not declared, causing a ReferenceError; replace the undefined TOKEN
by obtaining a real token via commonHelper.adminLogin() or by defining a
consistent placeholder token used across the file. Locate the failing usages
around the test suite (the req.set calls in the rolePermissionMapping.spec.js
tests) and either (a) call commonHelper.adminLogin() in a beforeAll/before hook
and assign the returned token to a module-scoped TOKEN variable, or (b) declare
a module-scoped const TOKEN = '<placeholder>' used by all tests; ensure any
async login is awaited and the variable is populated before tests run (e.g., set
TOKEN in beforeAll when using commonHelper.adminLogin()).
🟠 Major comments (33)
src/integration-tests-new/report-type/report-type.spec.js-46-74 (1)
46-74:⚠️ Potential issue | 🟠 MajorUpdate and delete tests hardcode
id=1, making them order-dependent and fragile.The update test (line 48) and delete test (line 66) both hardcode
?id=1. If the create test doesn't produceid=1, or if tests run in isolation/parallel, these will fail or operate on the wrong record. Capture theidfrom the create response and pass it to subsequent tests.Sketch
+let createdId + // In the create test: + createdId = res.body.result.id // In the update/delete tests: - const url = `/mentoring/v1/report-type/update?id=1` + const url = `/mentoring/v1/report-type/update?id=${createdId}`src/integration-tests-new/org-admin/schemas/org-admin.schemas.json-390-395 (1)
390-395:⚠️ Potential issue | 🟠 Major
updateThemeandthemeDetailsschemas are just{"type": "string"}.These two schemas only assert the response body is a string. The API almost certainly returns a JSON object with
responseCode,message,result, andmeta— matching the envelope pattern of every other endpoint in this file. As-is, these will either always fail (if the response is an object) or provide no meaningful validation.Define proper object schemas for these endpoints consistent with the rest of the file.
src/integration-tests-new/org-admin/schemas/org-admin.schemas.json-328-389 (1)
328-389:⚠️ Potential issue | 🟠 Major
uploadSampleCSVentry is a hardcoded response, not a JSON schema.Every other entry in this file is a JSON Schema (with
$schema,type,properties), but this one is a concrete response object with literal values ("responseCode": "OK", a specific correlation UUID, etc.). When used withtoMatchSchemain the test, this won't validate the response structure — it will either silently pass or fail unpredictably depending on the schema validator implementation.Replace this with an actual JSON Schema like the other entries, or if the intent is an exact-match assertion, use a different assertion method in the test (e.g.,
toMatchObject).src/integration-tests-new/org-admin/org-admin.spec.js-104-116 (1)
104-116:⚠️ Potential issue | 🟠 Major
uploadSampleCSVsends a bare string body and uses a non-schema for validation.Line 109 sends the literal string
'string'as the request body. A CSV upload endpoint likely expectsmultipart/form-datawith a file attachment, not a JSON string. Combined with the schema issue (the corresponding schema entry is a hardcoded response, not a JSON Schema), this test provides no meaningful coverage.src/integration-tests-new/org-admin/org-admin.spec.js-58-80 (1)
58-80:⚠️ Potential issue | 🟠 Major
updateRelatedOrgsrequest body looks like a response envelope, not a valid request payload.The POST body contains
responseCode,message,result, andmeta— these are response-shaped fields. The actual API likely expects organization IDs or a list of related orgs. This appears to be a copy-paste error from the schema/response definition.src/integration-tests-new/modules/schemas/modules.schemas.json-14-16 (1)
14-16:⚠️ Potential issue | 🟠 MajorInconsistent casing:
Id(line 15) vsid(lines 52, 121).The create schema uses
"Id"(capital I) while update and list schemas use"id"(lowercase). If the API consistently returnsid, this property will never be validated in the create response. If the API actually returnsIdfor create, the other schemas are wrong. Pick one and be consistent.Likely fix (assuming API returns lowercase `id`)
"result": { "type": "object", "properties": { - "Id": { + "id": { "type": "number" },src/integration-tests-new/modules/modules.spec.js-10-10 (1)
10-10:⚠️ Potential issue | 🟠 MajorReplace hardcoded
'string'auth token with valid authentication helpers.The auth token placeholder
'string'will cause requests to fail if authentication is enforced. Use the existing authentication helpers fromcommonTests.js(imported via@commonTests). The file exportslogIn(),mentorLogIn(), andadminLogin()functions that return user details with valid access tokens. Seesessions.specs.jsin the same directory for the correct pattern: invoke the helper inbeforeAll(), then use the returned token in request headers.Update lines 10, 26, 37, 53, 64, 77 to use a valid token rather than the placeholder.
src/integration-tests-new/feedback/schemas/feedback.schemas.json-89-89 (1)
89-89:⚠️ Potential issue | 🟠 MajorPOST submit schema is an empty object — validates nothing.
"POST_/mentoring/v1/feedback/submit/{SessionId}": {}matches any response body, sotoMatchSchemawill always pass regardless of what the server returns. Either define the expected response structure or add a comment explaining why schema validation is intentionally skipped.src/integration-tests-new/feedback/feedback.spec.js-10-10 (1)
10-10:⚠️ Potential issue | 🟠 MajorReplace hardcoded auth token with real token from test helper — tests expecting 200 will receive 401 instead.
Both the GET and POST "should return 200" tests set
x-auth-tokento the literal value'string', which is not a valid authentication token. These tests will fail unless the server is configured to accept any token. The codebase already has a proper pattern for obtaining real tokens viacommonHelper.logIn(),commonHelper.mentorLogIn(), orcommonHelper.adminLogin(), which call the login endpoint and extract the actualaccess_token. Update lines 10 and 29 to use one of these helpers instead of the placeholder token.src/integration-tests-new/question-set/question-set.spec.js-10-10 (1)
10-10:⚠️ Potential issue | 🟠 Major
x-auth-tokenset to literal'string'will cause test failures with 401/403 — replace with valid test tokens.These tests expect success responses (201, 202, 200) but use an invalid token value. The pattern in other test files shows real tokens should come from test setup (e.g.,
userDetails.token,mentorDetails.token). ThecommonTests.jsfile provides this setup. Either import the shared test utilities to obtain real tokens, or if these endpoints truly accept any string, confirm that behavior explicitly.Note: The separate unauthorized tests (lines 24–28, 49–53, 68–72) correctly omit the token to expect 401/403.
src/integration-tests-new/permissions/schemas/permissions.schemas.json-12-31 (1)
12-31:⚠️ Potential issue | 🟠 MajorSchemas lack
requiredproperties, making validation effectively a no-op.Without
requiredarrays, any object (including{}) will pass validation against these schemas. This defeats the purpose of schema-based response validation in tests. Consider addingrequiredat each level to actually assert the response shape.For example, for the create response:
Proposed fix
"result": { "type": "object", "properties": { "Id": { "type": "number" }, "status": { "type": "string" }, "module": { "type": "string" }, "request_type": { "type": "array", "items": { "type": "string" } } - } + }, + "required": ["Id", "status", "module", "request_type"] },The same applies to all four schemas in this file (and likely to other schema files in this PR following the same pattern).
src/integration-tests-new/permissions/permissions.spec.js-10-10 (1)
10-10:⚠️ Potential issue | 🟠 MajorUse shared authentication helpers instead of hardcoded
'string'token.The
permissions.spec.jsfile hardcodes'x-auth-token'to the literal value'string'instead of using the real authentication tokens fromcommonTestshelper. This will cause 401/403 failures against any real server. Other test files (sessions.specs.js, mentees.specs.js) properly usecommonHelper.logIn()orcommonHelper.mentorLogIn()in abeforeAll()block and pass real tokens via the'n'header. Apply the same pattern here.src/integration-tests-new/reports/reports.spec.js-75-86 (1)
75-86:⚠️ Potential issue | 🟠 MajorUpdate test uses literal
"string"as path param and sendsconfigas a string instead of an object.
- The URL
/mentoring/v1/reports/update/stringuses the literal word "string" as the ID — this won't match any real resource.configis sent as'string'(line 84) but the create endpoint and schema define it as an object. This inconsistency will likely trigger a validation error, making the test untestable even with a valid token.These look like unresolved auto-generation placeholders that need real or dynamically obtained values.
src/integration-tests-new/reports/schemas/reports.schemas.json-1-139 (1)
1-139:⚠️ Potential issue | 🟠 MajorSchemas lack
requiredproperties at the top level, making validation extremely permissive.None of the schemas enforce
required: ["responseCode", "message", "result"]on the root object, nor do mostresultobjects haverequiredarrays. This means an empty{}response body would pass schema validation, defeating the purpose of these checks.Add
requiredfields at the envelope level and onresultproperties for meaningful validation.src/integration-tests-new/reports/reports.spec.js-61-66 (1)
61-66:⚠️ Potential issue | 🟠 MajorGET read endpoint should not return 201.
A
GETrequest for reading a resource conventionally returns200 OK, not201 Created. Line 66 assertstoBe(201)which is almost certainly wrong — either the test expectation or the API itself needs correction.- test('should return 201', async () => { + test('should return 200', async () => { const url = `/mentoring/v1/reports/read?id=1` let req = request(BASE).get(url) req = req.set('x-auth-token', 'bearer {{token}}') const res = await req - expect(res.status).toBe(201) + expect(res.status).toBe(200)src/integration-tests-new/reports/schemas/reports.schemas.json-216-289 (1)
216-289:⚠️ Potential issue | 🟠 MajorFix update schema:
configshould be"type": "object", matching the database column type and other endpoints.The database model defines
configasDataTypes.JSONB, which becomes a JavaScript object when retrieved. Both the create and read endpoints correctly defineconfigas"type": "object". The update schema incorrectly defines it as"type": "string". Since all responses return the same database field with the same type, the update schema must be corrected to"type": "object"to match.src/package.json-75-75 (1)
75-75:⚠️ Potential issue | 🟠 Majorjest-json-schema@^6.1.0 is incompatible with Jest 30—upgrade required before proceeding.
jest-json-schema has not been updated in ~4 years and declares Node engine constraints (
Node 12/14/15+) that conflict with Jest 30's minimum Node 18.x requirement. Additionally, it depends on an outdated jest-matcher-utils@^27.3.1, creating dependency conflicts with Jest 30's bundled utilities. This package must be upgraded or replaced before the Jest upgrade.jest-junit@^14.0.1 is compatible with Jest 30 and requires no changes.
Verify the following before upgrading Jest to 30:
- Node.js version: Add
.nvmrcor document the minimum Node version (≥18.x) in project documentation. Your CI/CD pipelines must enforce Node 18+.- jest-json-schema: Upgrade to a Jest 30-compatible version, or remove if no longer needed.
- jest.config.js: Already clean; no deprecated options detected.
- Breaking changes: The CLI flag
--testPathPatternhas been renamed to--testPathPatterns. Test your scripts accordingly. TypeScript support now requires version ≥5.4.src/integration-tests-new/testSequencer.js-23-23 (1)
23-23:⚠️ Potential issue | 🟠 MajorInconsistent base path:
integration-testsvsintegration-tests-new.Line 23 correctly resolves relative paths against
integration-tests-new, but lines 43 and 50 useintegration-tests. This will produce wrong relative paths in the warning log and the final execution order log, and more critically, could cause the remaining-tests warning to always fire (since the relative paths won't match theexecutionOrderentries if derived from the wrong base).Proposed fix
- remainingTests.map((t) => path.relative(path.join(process.cwd(), 'integration-tests'), t.path)) + remainingTests.map((t) => path.relative(path.join(process.cwd(), 'integration-tests-new'), t.path))- console.log(`${index + 1}. ${path.relative(path.join(process.cwd(), 'integration-tests'), test.path)}`) + console.log(`${index + 1}. ${path.relative(path.join(process.cwd(), 'integration-tests-new'), test.path)}`)Also applies to: 43-43, 50-50
src/integration-tests-new/report-mapping/report-mapping.spec.js-49-49 (1)
49-49:⚠️ Potential issue | 🟠 MajorHardcoded
id=16for update and delete assumes pre-existing data.Both update (Line 49) and delete (Line 68) reference
id=16. This ID may not exist in a clean test database. Additionally, if tests run in order, the delete could remove the record before any re-run of update. Consider creating a record first and using its ID dynamically.Also applies to: 68-68
src/integration-tests-new/questions/questions.spec.js-47-49 (1)
47-49:⚠️ Potential issue | 🟠 MajorHardcoded resource IDs (
1) assume pre-existing data.
update/1(Line 49) andread/1(Line 86) rely on question ID1existing in the test database. If the create test runs first and produces a different ID, or if the database is empty, these tests will fail. Capture the ID from the create response and use it in subsequent tests (similar torequestSessions.specs.js's lifecycle pattern).Also applies to: 84-86
src/integration-tests-new/commonTests.js-185-205 (1)
185-205:⚠️ Potential issue | 🟠 MajorAuth token format inconsistency between login helpers and
waitForProfileExtension.In the login functions (e.g., Line 40), the
x-auth-tokenheader is set as'bearer ' + token. ButwaitForProfileExtension(Line 193) sets'x-auth-token'to the raw token (without the'bearer 'prefix), and it's called withres.body.result.access_tokendirectly (Line 36). If the server expects a consistent format, one of these will fail.Also applies to: 36-36, 40-40
src/integration-tests-new/commonTests.js-22-53 (1)
22-53:⚠️ Potential issue | 🟠 MajorReturned
passwordinuserDetailsis the random faker password, not the actual hardcoded one.Line 23 generates
faker.internet.password(), but the account is created and logged in with the hardcoded'PassworD@@@123'(Lines 27, 33). The faker-generated password is then stored in the returneduserDetails.password(Line 53). Any downstream code relying onuserDetails.password(e.g., to re-authenticate) would fail. The same issue exists inmentorLogIn(Line 78 vs 83/90, stored at Line 108).🐛 Proposed fix
const logIn = async () => { try { let request = defaults(supertest('http://localhost:3001')) let waitOn = require('wait-on') let opts = { resources: [baseURL], delay: 1000, interval: 1000, timeout: 60000, } await waitOn(opts) let email = 'adithya' + crypto.randomBytes(5).toString('hex') + '@tunerlabs.com' - let password = faker.internet.password() + let password = 'PassworD@@@123' let res = await request.post('/user/v1/account/create').set('origin', 'localhost').send({ name: 'adithya', email: email, - password: 'PassworD@@@123', + password: password, role: common.MENTEE_ROLE, }) res = await request.post('/user/v1/account/login').set('origin', 'localhost').send({ identifier: email, - password: 'PassworD@@@123', + password: password, })Apply the same pattern to
mentorLogIn.src/integration-tests-new/users/users.spec.js-19-29 (1)
19-29:⚠️ Potential issue | 🟠 MajorSame hardcoded token issue; also minor typo
"jhon"→"john".Same fix needed for the auth token. The search query param has a typo which, while not breaking, makes the test intent unclear.
.circleci/config.yml-118-130 (1)
118-130:⚠️ Potential issue | 🟠 MajorHealth-check loop never fails the build if containers remain unhealthy.
After 30 attempts the loop silently falls through and the pipeline proceeds to run migrations against potentially broken services. Add an explicit failure after the loop.
Proposed fix
echo "Waiting... attempt $i" docker ps --format "table {{.Names}}\t{{.Status}}" sleep 5 done + + # Fail if containers are still not healthy + unhealthy=$(docker ps --filter "health=unhealthy" --format "{{.Names}}") + starting=$(docker ps --filter "health=starting" --format "{{.Names}}") + if [ -n "$unhealthy" ] || [ -n "$starting" ]; then + echo "ERROR: Containers not healthy after 30 attempts: $unhealthy $starting" + docker ps --format "table {{.Names}}\t{{.Status}}" + exit 1 + fi.circleci/config.yml-178-197 (1)
178-197:⚠️ Potential issue | 🟠 MajorOverwriting
$USERenv variable can break subsequent commands.
USERis a standard POSIX environment variable (current username). Overwriting it with a container name (e.g., Line 181, 188, 195) may cause unexpected behavior in tools that rely on$USER. Use a different variable name likeUSER_CONTAINER.Proposed fix
- export USER=$(docker ps --format "{{.Names}}" | grep user) - echo "Running user migrations in $USER" - docker exec "$USER" npm run db:init + export USER_CONTAINER=$(docker ps --format "{{.Names}}" | grep user) + echo "Running user migrations in $USER_CONTAINER" + docker exec "$USER_CONTAINER" npm run db:initApply the same rename in the seeder and start-service steps.
src/integration-tests-new/connections/connections.specs.js-8-11 (1)
8-11:⚠️ Potential issue | 🟠 Major
adminDetailsis assigned withoutlet/constdeclaration and is never used.Line 10 assigns to
adminDetailswithout declaring it, creating an implicit global (or throwing in strict mode). Additionally, this variable is never referenced in any test — thebeforeAllandadminLogin()call appear unnecessary.Proposed fix — remove unused admin login or declare the variable
If admin context is not needed, remove the
beforeAllblock entirely:-beforeAll(async () => { - console.log('Attempting to login...') - adminDetails = await commonHelper.adminLogin() -})src/integration-tests-new/profile/schemas/profile.schemas.json-146-161 (1)
146-161:⚠️ Potential issue | 🟠 MajorFix inconsistent meta field naming: Line 158 uses
meeting_platformbut should usemeetingPlatform.The API responses use
meetingPlatform(camelCase), as confirmed by Postman collection examples and test expectations. The schema at line 158 (POST_mentoring_v1_profile_create) incorrectly usesmeeting_platform(snake_case), while lines 258 and 451 correctly usemeetingPlatform. Update line 158 to match the API response format.src/integration-tests-new/users/users.spec.js-7-16 (1)
7-16:⚠️ Potential issue | 🟠 MajorTests use a hardcoded placeholder
'string'as the auth token — these will fail with 401.Other test files in this PR (e.g.,
connections.specs.js,profile.specs.js) usecommonHelper.logIn()to obtain a real token. This file skips that entirely, sending a literal'string'asx-auth-token, so the server will reject the request.Proposed fix
const request = require('supertest') const BASE = process.env.BASE_URL || 'http://localhost:3000' const schemas = require('./schemas/users.schemas.json') +const commonHelper = require('@commonTests') + +let userDetails = null + +beforeAll(async () => { + userDetails = await commonHelper.logIn() +}) describe('users endpoints generated from api-doc.yaml', () => { describe('GET /mentoring/v1/users/pendingFeedbacks', () => { test('should return 200', async () => { const url = `/mentoring/v1/users/pendingFeedbacks` let req = request(BASE).get(url) - req = req.set('x-auth-token', 'string') + req = req.set('x-auth-token', userDetails.token) const res = await req expect(res.status).toBe(200)src/integration-tests-new/report-queries/report-queries.spec.js-7-16 (1)
7-16:⚠️ Potential issue | 🟠 MajorPOST create test sends no request body.
The
createendpoint test (line 7-16) never calls.send(...)with a payload. Without a body, the endpoint likely cannot create a resource and won't return 200. The 400/422 negative test on lines 18-25 sends an empty body{}, but the happy-path test sends nothing at all.src/integration-tests-new/issues/issues.spec.js-10-10 (1)
10-10:⚠️ Potential issue | 🟠 MajorHardcoded placeholder
'string'as auth token — test will fail with 401.Other test suites in this PR (e.g.,
mentees.specs.js) usecommonHelper.logIn()orcommonHelper.adminLogin()to obtain a real token. This test should do the same, or it will never actually validate the 200 path.src/integration-tests-new/cloud-services/cloud-services.spec.js-7-16 (1)
7-16:⚠️ Potential issue | 🟠 MajorPlaceholder auth token and missing query parameters will cause test failures.
Same as other files:
'string'is not a valid token. Additionally,getSignedUrlandgetDownloadableUrlendpoints typically require query parameters (e.g., file name/path) to return a meaningful response. Without them, even an authenticated request is unlikely to succeed with 200.src/integration-tests-new/admin/admin.spec.js-1-16 (1)
1-16:⚠️ Potential issue | 🟠 MajorHardcoded
'string'auth token will cause test failures or bypass authentication.Unlike other test files in this PR (e.g.,
entity.specs.js,default-rule.specs.js) which usecommonHelper.adminLogin()to obtain a real token, this file setsx-auth-tokento the literal'string'. These are admin-only endpoints — the tests will either fail with 401/403 or only pass if auth is misconfigured.Also,
toMatchSchemarequiresjest-json-schemato be configured (e.g., viaexpect.extend). Verify this is set up globally; otherwise every schema assertion will throw.Proposed fix
const request = require('supertest') const BASE = process.env.BASE_URL || 'http://localhost:3000' const schemas = require('./schemas/admin.schemas.json') +const commonHelper = require('@commonTests') + +let adminDetails = null + +beforeAll(async () => { + adminDetails = await commonHelper.adminLogin() +}) describe('admin endpoints generated from api-doc.yaml', () => { describe('DELETE /mentoring/v1/admin/userDelete', () => { test('should return 200', async () => { const url = `/mentoring/v1/admin/userDelete` let req = request(BASE).delete(url) - req = req.set('x-auth-token', 'string') + req = req.set('x-auth-token', adminDetails.token)src/integration-tests-new/sessions/sessions.specs.js-15-17 (1)
15-17:⚠️ Potential issue | 🟠 MajorLogging full user details (including tokens) to stdout.
console.log(userDetails)andconsole.log(menteeDetails)will print access tokens and refresh tokens to CI logs, which is a security concern. Remove or redact sensitive fields.Proposed fix
- console.log(userDetails) - console.log(menteeDetails) - console.log('line 18') + console.log('Test users initialized. Mentor userId:', userDetails.userId, 'Mentee userId:', menteeDetails.userId)
🟡 Minor comments (38)
src/integration-tests-new/report-type/report-type.spec.js-35-35 (1)
35-35:⚠️ Potential issue | 🟡 MinorRead test queries
title=random_title— may not match any record.If
random_titledoesn't correspond to an existing report type, the API may return a 404 or empty result, causing the 200 assertion or schema validation to fail. Use the title from the previously created record to ensure a meaningful response.src/integration-tests-new/report-type/schemas/report-type.schemas.json-26-28 (1)
26-28:⚠️ Potential issue | 🟡 Minor
deleted_attyped as only"null"— will break for soft-deleted records.If any response returns a timestamp string for
deleted_at, validation will fail. Use"type": ["string", "null"]to accept both states.src/integration-tests-new/org-admin/schemas/org-admin.schemas.json-100-102 (1)
100-102:⚠️ Potential issue | 🟡 Minor
deleted_attyped as"null"only — will reject string timestamps.If a record is soft-deleted and
deleted_atgets populated with a timestamp string, this schema will reject it. Consider using a union type:Proposed fix
"deleted_at": { - "type": "null" + "type": ["string", "null"] }src/integration-tests-new/org-admin/org-admin.spec.js-118-137 (1)
118-137:⚠️ Potential issue | 🟡 MinorInconsistent auth header casing:
X-auth-tokenvsx-auth-token.Line 122 uses
X-auth-token(capital X) while all other tests usex-auth-token. While HTTP headers are case-insensitive per spec, inconsistency can cause confusion and may matter if the server-side middleware does a case-sensitive lookup.Proposed fix
- req = req.set('X-auth-token', 'bearer {{token}}') + req = req.set('x-auth-token', 'bearer {{token}}')src/integration-tests-new/feedback/schemas/feedback.schemas.json-25-27 (1)
25-27:⚠️ Potential issue | 🟡 MinorNull-only types will break if the API ever returns actual values.
options,category, anddeleted_atare typed as"type": "null", meaning validation will fail as soon as these fields carry a real value (e.g., an array of options, a category string, or a timestamp). Use a union type to accept both cases.Proposed fix
"options": { - "type": "null" + "type": ["array", "null"] },"category": { - "type": "null" + "type": ["string", "null"] },"deleted_at": { - "type": "null" + "type": ["string", "null"] },Also applies to: 37-39, 72-74
src/integration-tests-new/question-set/question-set.spec.js-13-13 (1)
13-13:⚠️ Potential issue | 🟡 Minor
questions: [1]sends a number, but the schema definesquestionsas an array of strings.The request payload sends
questions: [1](number), while the JSON schema at Lines 20-25 specifies"items": { "type": "string" }. Either the payload or schema is wrong.src/integration-tests-new/question-set/schemas/question-set.schemas.json-55-56 (1)
55-56:⚠️ Potential issue | 🟡 MinorFix field naming in create and update schemas:
meeting_platformshould bemeetingPlatform.The read schema at line 169 correctly uses
meetingPlatform(camelCase), matching the actual API responses documented in the Postman collection. The create and update schemas at lines 55 and 115 incorrectly usemeeting_platform(snake_case) and should be updated to match. This mismatch will silently pass validation due to the absence of required fields, potentially causing runtime errors when the API expects camelCase keys.src/integration-tests-new/permissions/schemas/permissions.schemas.json-14-16 (1)
14-16:⚠️ Potential issue | 🟡 MinorInconsistent casing:
Idvsidacross schemas.The create and update schemas use
Id(capital I) at Line 15, while the list schema usesid(lowercase) at Line 136. If the API actually returns different casings for different endpoints, this is fine but surprising. Otherwise, one of them is wrong and the test will silently pass due to the missingrequiredfields noted above.Also applies to: 136-138
src/integration-tests-new/reports/reports.spec.js-109-129 (1)
109-129:⚠️ Potential issue | 🟡 Minor
POST /reports/reportDataasserting 201 is likely incorrect.This endpoint retrieves/generates report data — it's a query, not a resource creation. The expected status should probably be
200, not201.Also, the extremely long query string on line 111 with placeholder values like
organization=stringandgroup_by=stringreduces readability and won't match real data. Consider building the query params programmatically.src/integration-tests-new/reports/schemas/reports.schemas.json-104-106 (1)
104-106:⚠️ Potential issue | 🟡 Minor
deleted_attyped as"null"will fail validation when a record is actually soft-deleted.If a deleted record returns a timestamp string in
deleted_at, the schema will reject it. Consider using"type": ["string", "null"]to handle both states.Proposed fix (apply to all occurrences)
"deleted_at": { - "type": "null" + "type": ["string", "null"] }Also applies to: 180-182, 255-257
src/package.json-14-14 (1)
14-14:⚠️ Potential issue | 🟡 Minor
devscript does not setNODE_ENV, unlike all other run scripts.Every other script (
start,prod,stage,qa) explicitly setsNODE_ENV. If the application relies onNODE_ENVfor configuration (e.g., database connections, logging levels), runningnpm run devwill use whatever is in the shell environment orundefined, which may cause unexpected behavior.Proposed fix
- "dev": "node app.js", + "dev": "NODE_ENV=development node app.js",src/integration-tests-new/form/form.specs.js-15-15 (1)
15-15:⚠️ Potential issue | 🟡 MinorTest description says "200" but assertion expects
201.Line 15 says
'should return 200'but line 71 assertsres.statusto be201. This is misleading. Update the description to match the expected status code.Proposed fix
- test('should return 200', async () => { + test('should return 201', async () => {Also applies to: 71-71
src/integration-tests-new/form/schemas/form.schemas.json-128-130 (1)
128-130:⚠️ Potential issue | 🟡 MinorFix inconsistent field name in update schema: change
meeting_platformtomeetingPlatform.The create (line 128) and read (line 303) schemas use
meetingPlatform(camelCase), but the update schema (line 170) usesmeeting_platform(snake_case). The actual API response construction insrc/helpers/responses.jsand all other schema files consistently use camelCase. Update line 170 to match.src/integration-tests-new/report-mapping/schemas/report-mapping.schemas.json-2-2 (1)
2-2:⚠️ Potential issue | 🟡 MinorInconsistent schema key naming convention across schema files.
The keys here use underscore-separated format (
POST_mentoring_v1_report-mapping_create) while other schema files in this directory (e.g.,questions.schemas.json) use URL-path-style keys with slashes (POST_/mentoring/v1/questions/create). While each test correctly references its own schema keys, this inconsistency in naming convention across schema files creates maintenance confusion and makes it unclear which format to use for future schema files. Standardize all schema key formats to match a single convention.src/integration-tests-new/requestSessions/schemas/requestSessions.schemas.json-20-22 (1)
20-22:⚠️ Potential issue | 🟡 MinorInconsistent
idtype:numberin create vsstringin list/getDetails.The
POST_mentoring_v1_requestSessions_createschema definesidas"type": "number"(Line 21), butGET_mentoring_v1_requestSessions_listdefines it as"type": "string"(Line 113), and similarlyGET_mentoring_v1_requestSessions_getDetailsuses"string"(Line 238). If the API returns a consistent type, one of these is wrong and will silently pass or fail schema validation depending on the actual response.Verify what the API actually returns and align all schemas.
Also applies to: 112-114
src/integration-tests-new/role-extension/role-extension.spec.js-10-11 (1)
10-11:⚠️ Potential issue | 🟡 MinorRedundant
x-auth-tokenheader set — second call overwrites first.Line 10 sets the header to
'bearer {{token}}'and Line 11 immediately overwrites it with'test-token'. The first.set()is dead code. The same pattern appears on Lines 36-37. Neither value is a valid token — see the broader placeholder issue across this file.Also applies to: 36-37
src/integration-tests-new/requestSessions/requestSessions.specs.js-39-40 (1)
39-40:⚠️ Potential issue | 🟡 MinorComment says "5 days" but code adds 10 days.
Line 40:
startDate.setDate(now.getDate() + 10)adds 10 days, but the comment on the same line says "5 days in the future."Fix
- startDate.setDate(now.getDate() + 10) // 5 days in the future + startDate.setDate(now.getDate() + 10) // 10 days in the futuresrc/integration-tests-new/requestSessions/requestSessions.specs.js-1-1 (1)
1-1:⚠️ Potential issue | 🟡 MinorMisleading comment: timeout is 60 seconds, not 30.
jest.setTimeout(60000)sets a 60-second timeout, but the comment says "Set default timeout to 30 seconds."Fix
-jest.setTimeout(60000) // Set default timeout to 30 seconds +jest.setTimeout(60000) // Set default timeout to 60 secondssrc/integration-tests-new/profile/schemas/profile.schemas.json-265-265 (1)
265-265:⚠️ Potential issue | 🟡 MinorEmpty schema
{}provides no validation for the filterList endpoint.
GET_mentoring_v1_profile_filterList_entity_types_entity_typesis defined as{}, which matches any response body. The corresponding test atprofile.specs.js:44will always pass regardless of the actual response shape. Either define a proper schema or add a TODO to track this.src/integration-tests-new/connections/schemas/connections.schemas.json-46-48 (1)
46-48:⚠️ Potential issue | 🟡 MinorFields like
deleted_at,designation,experienceare typed as"type": "null"only — schema will reject non-null values.This appears in multiple places (Lines 46-48, 125-127, 149-151, 170-172, 365-367, 389-391, 413-415, 544-546). If the API ever returns an actual value (e.g., a timestamp for
deleted_aton a soft-deleted record, or a string fordesignation), validation will fail. Consider using union types like"type": ["string", "null"]..circleci/config.yml-137-139 (1)
137-139:⚠️ Potential issue | 🟡 Minor
grep mentoringmay match multiple containers (e.g.,mentoring,mentoring-db).Consider using a more specific pattern like
grep -w mentoringorgrep '^mentoring$'(depending on naming convention) to avoid ambiguity. Same applies togrep useron Lines 181, 188, 195.src/integration-tests-new/connections/connections.specs.js-15-15 (1)
15-15:⚠️ Potential issue | 🟡 MinorTest descriptions say "should return 200" but assertions expect 201.
Lines 15, 37, and 68 all describe the test as returning 200, while the actual assertions on Lines 29, 60, and 91 check for 201. Update the descriptions to match.
Proposed fix
- test('should return 200', async () => { + test('should return 201', async () => {Apply to all three test blocks.
src/integration-tests-new/issues/schemas/issues.schemas.json-21-25 (1)
21-25:⚠️ Potential issue | 🟡 MinorFix
formsVersionschema to match actual API response structure.The issues schema defines
formsVersionitems as plain strings, but the API returns objects withid,type, andversionproperties (confirmed in connections schema and actual API responses). Update the items type from"type": "string"to an object with the three properties to match what the API actually returns.src/integration-tests-new/mentoring/schemas/mentoring.schemas.json-57-64 (1)
57-64:⚠️ Potential issue | 🟡 Minor
erranderrMsgrequired as"type": "string"in check items — may fail for healthy checks.If healthy checks return
nullor omiterr/errMsg, validation will fail. Consider using"type": ["string", "null"]to allow both, or remove them fromrequiredif they're only present on unhealthy checks.src/integration-tests-new/issues/issues.spec.js-13-13 (1)
13-13:⚠️ Potential issue | 🟡 MinorTypo:
descriptaionshould bedescription.This will send an unrecognized field to the API, so the actual description won't be set in the request payload.
Proposed fix
- descriptaion: 'string', + description: 'string',src/integration-tests-new/entity-type/schemas/entity-type.schemas.json-52-54 (1)
52-54:⚠️ Potential issue | 🟡 MinorSuspicious
field_0property — likely an auto-generation artifact.This
field_0field sits at the top level of the response envelope alongsideresponseCode,message,result, andmeta. It doesn't appear in any other schema in this PR and looks like a leftover from code generation. If the API doesn't actually return this field, it's harmless (norequiredconstraint), but it adds confusion.src/integration-tests-new/mentees/schemas/mentees.schemas.json-152-177 (1)
152-177:⚠️ Potential issue | 🟡 Minor
reportsschema usesresponse_code(snake_case) while all other schemas useresponseCode(camelCase).Line 155 defines
response_codeinstead of theresponseCodepattern used consistently across every other schema in this PR. If the actual API response usesresponseCode, this property will never be validated. Verify against the real API response and align accordingly.src/integration-tests-new/entity-type/schemas/entity-type.schemas.json-55-65 (1)
55-65:⚠️ Potential issue | 🟡 MinorInconsistent
metafield naming across schemas:meeting_platformvsmeetingPlatform.The create, read, and delete schemas use
meeting_platform(snake_case) inmeta, while the update schema usesmeetingPlatform(camelCase). If the API returns a consistent field name, one set of schemas will silently pass validation (since properties aren't required) but won't actually validate the field. Align the naming to match the actual API response.Also applies to: 221-238
src/integration-tests-new/cloud-services/schemas/cloud-services.schemas.json-28-28 (1)
28-28:⚠️ Potential issue | 🟡 Minor
getDownloadableUrlschema is empty — no response validation will occur.An empty schema
{}matches any JSON value, sotoMatchSchemawill always pass regardless of what the endpoint returns. Either define the expected response structure or add a TODO comment indicating this is pending.src/integration-tests-new/admin/admin.spec.js-6-16 (1)
6-16:⚠️ Potential issue | 🟡 MinorDELETE
/admin/userDeletetest sends no request body or query params.A user-delete endpoint typically requires identifying which user to delete. Sending a bare DELETE with no payload is unlikely to succeed meaningfully, and expecting a
200may mask the real behavior (e.g., 400 for missing params). Consider providing a valid user ID in the request body or as a query parameter, consistent with the API contract.src/integration-tests-new/default-rule/default-rule.specs.js-80-81 (1)
80-81:⚠️ Potential issue | 🟡 MinorTest descriptions say "should return 200" but assertions expect 202.
Line 81 says
'should return 200 on successful update'while Line 129 assertstoBe(202). Similarly, Line 136 says'should return 200 on successful deletion'while Line 172 assertstoBe(202). Update the descriptions to match.Proposed fix
- test('should return 200 on successful update', async () => { + test('should return 202 on successful update', async () => {- test('should return 200 on successful deletion', async () => { + test('should return 202 on successful deletion', async () => {Also applies to: 135-136
src/integration-tests-new/entity/entity.specs.js-190-193 (1)
190-193:⚠️ Potential issue | 🟡 MinorMissing
org-idheader on DELETE request, unlike create/update/read tests.The create (Line 38), update (Line 93), and read (Line 147) tests all set the
org-idheader, but the delete test omits it. If the API requiresorg-idfor authorization scoping, this test may pass only coincidentally or fail in stricter environments.Proposed fix
const url = `/mentoring/v1/entity/delete/${entityId}` let req = request(BASE).delete(url) req = req.set('x-auth-token', adminDetails.token) +req = req.set('org-id', adminDetails.organizations[0].id.toString()) const res = await reqsrc/integration-tests-new/default-rule/default-rule.specs.js-53-55 (1)
53-55:⚠️ Potential issue | 🟡 MinorDuplicate status assertion on Lines 54–55.
expect(res.status).toBe(201)is asserted twice. Also,createdRuleId(Line 54) is never referenced by subsequent tests since update and delete tests create their own rules — consider removing the variable entirely.Proposed fix
const res = await req expect(res.status).toBe(201) - createdRuleId = res.body.result.id // Save the ID for update/delete tests - expect(res.status).toBe(201) // validate response schema expect(res.body).toMatchSchema(schemas['POST_mentoring_v1_default-rule_create'])src/integration-tests-new/sessions/schemas/sessions.schemas.json-260-262 (1)
260-262:⚠️ Potential issue | 🟡 MinorEmpty schemas provide no validation value.
The schemas for
enroll,unenroll, andstartare empty objects ({}), which will match any response body. The session specs (e.g.,sessions.specs.jslines 86–87 and 103–104) calltoMatchSchema(schema)against these, making validation a no-op.Define at least the standard envelope (
responseCode,message,result) for these endpoints so the schema checks are meaningful.src/integration-tests-new/sessions/schemas/sessions.schemas.json-496-498 (1)
496-498:⚠️ Potential issue | 🟡 MinorSame empty-schema issue for recording and completed endpoints.
getRecording,completed, andupdateRecordingUrlschemas are also empty{}, providing no validation. Consider filling these in or removing the schema validation calls until the schemas are ready.src/integration-tests-new/sessions/sessions.specs.js-65-71 (1)
65-71:⚠️ Potential issue | 🟡 MinorTest name says "should return 200 on success" but asserts
toBe(201).This is misleading. Update the test name to match the expected status code.
Proposed fix
- test('GET /mentoring/v1/sessions/details/{sessionId} - should return 200 on success', async () => { + test('GET /mentoring/v1/sessions/details/{sessionId} - should return 201 on success', async () => {src/integration-tests-new/sessions/sessions.specs.js-286-331 (1)
286-331:⚠️ Potential issue | 🟡 MinorShadowed
userDetailsvariable in feedbackbeforeAll.Line 290 declares
let userDetails = await commonHelper.mentorLogIn(), shadowing the outer-scopeuserDetails. The feedback submission test at line 358 then uses the outeruserDetails(which is also a mentor). This works by coincidence since both are mentor logins, but it's fragile and confusing. Use a distinct variable name likefeedbackMentor.Proposed fix
- let userDetails = await commonHelper.mentorLogIn() + const feedbackMentor = await commonHelper.mentorLogIn()Then replace all
userDetailsreferences within thisbeforeAll(lines 300, 308, 324, 329) withfeedbackMentor, and update line 358 similarly.src/integration-tests-new/sessions/schemas/sessions.schemas.json-152-154 (1)
152-154:⚠️ Potential issue | 🟡 Minor
organization_idsshould be typed as"array", not"string".The database schema defines
organization_idsasARRAY(STRING)(migration line 107-110), and configuration files access it as an array using index notation (data.organization_ids[0]). However, the integration test schema at line 152-154 incorrectly types it as"string", creating a mismatch with the actual data structure and theorganization_idfield below it (which is correctly typed as an array at lines 176-180).
| "operator": { | ||
| "type": "string" | ||
| }, |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# First, let's read the schema file to see the relevant sections
cat -n src/integration-tests-new/default-rule/schemas/default-rule.schemas.json | head -150Repository: ELEVATE-Project/mentoring
Length of output: 3894
🏁 Script executed:
#!/bin/bash
# Let's see more of the schema file, especially the update and delete sections
tail -n +100 src/integration-tests-new/default-rule/schemas/default-rule.schemas.json | head -300Repository: ELEVATE-Project/mentoring
Length of output: 4684
🏁 Script executed:
#!/bin/bash
# Search for controller/model files handling default-rule
find . -type f \( -name "*default*rule*" -o -name "*defaultRule*" \) ! -path "*/node_modules/*" | head -20Repository: ELEVATE-Project/mentoring
Length of output: 695
🏁 Script executed:
#!/bin/bash
# Check the controller to see what field names are returned
cat -n src/controllers/v1/default-rule.js | head -200Repository: ELEVATE-Project/mentoring
Length of output: 4207
🏁 Script executed:
#!/bin/bash
# Check the service to see what fields are returned
cat -n src/services/default-rule.js | head -300Repository: ELEVATE-Project/mentoring
Length of output: 12568
🏁 Script executed:
#!/bin/bash
# Continue reading the service file for read methods
tail -n +300 src/services/default-rule.js | head -200Repository: ELEVATE-Project/mentoring
Length of output: 3944
🏁 Script executed:
#!/bin/bash
# Check the database model to see the actual field names in the database
cat -n src/database/models/defaultRules.jsRepository: ELEVATE-Project/mentoring
Length of output: 2698
🏁 Script executed:
#!/bin/bash
# Check the database queries to see if there's any field transformation
cat -n src/database/queries/defaultRule.jsRepository: ELEVATE-Project/mentoring
Length of output: 5175
🏁 Script executed:
#!/bin/bash
# Check the test file to see what fields are expected in responses
cat -n src/integration-tests-new/default-rule/default-rule.specs.js | head -300Repository: ELEVATE-Project/mentoring
Length of output: 7679
Fix read schema field names: matching_operator → operator and role_config → requester_roles_config.
The database model and service return operator and requester_roles_config, but the read schema (line 135-137) expects matching_operator and role_config. This mismatch will cause read responses to fail schema validation. The create and update schemas correctly use operator and requester_roles_config.
Additionally, add required arrays to the read schema item properties to catch such field name discrepancies during testing.
🤖 Prompt for AI Agents
In `@src/integration-tests-new/default-rule/schemas/default-rule.schemas.json`
around lines 35 - 37, Update the read schema in default-rule.schemas.json so the
item properties use "operator" (not "matching_operator") and
"requester_roles_config" (not "role_config") to match the database model and
service, and add appropriate "required" arrays to the read schema's item
properties to validate presence of expected fields; locate the read schema
section that defines the item object (where "matching_operator" and
"role_config" currently appear) and rename those keys to "operator" and
"requester_roles_config" and include a "required": [...] list containing the
required property names for that item.
| expect(res.status).toBe(200) | ||
| // validate response schema | ||
| const schema = schemas['GET_/mentoring/v1/feedback/forms/{SessionId}'] | ||
| expect(res.body).toMatchSchema(schema) |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Search for jest-json-schema and custom matcher setup
rg -rn "toMatchSchema|jest-json-schema|addSchema|matchers" --type=js --type=json -g '*integration-tests-new*' 2>/dev/null | head -50Repository: ELEVATE-Project/mentoring
Length of output: 51
🏁 Script executed:
#!/bin/bash
# Check for jest configuration and setup files
find . -maxdepth 3 \( -name "jest.config.*" -o -name "setupTests.*" -o -name "setup.js" \) -o -name "package.json" | head -20Repository: ELEVATE-Project/mentoring
Length of output: 108
🏁 Script executed:
#!/bin/bash
# Check if jest-json-schema is in package.json dependencies
rg '"jest-json-schema"' . --type=json 2>/dev/nullRepository: ELEVATE-Project/mentoring
Length of output: 119
🏁 Script executed:
#!/bin/bash
# Look at the feedback test file to understand the test structure
head -50 src/integration-tests-new/feedback/feedback.spec.js 2>/dev/null | cat -nRepository: ELEVATE-Project/mentoring
Length of output: 2099
🏁 Script executed:
#!/bin/bash
# Read jest.config.js to see how jest-json-schema is configured
cat -n src/jest.config.jsRepository: ELEVATE-Project/mentoring
Length of output: 759
🏁 Script executed:
#!/bin/bash
# Search more broadly for jest-json-schema setup or addSchema calls
rg "jest-json-schema|addSchema|setupFilesAfterEnv" --type=js 2>/dev/null | head -30Repository: ELEVATE-Project/mentoring
Length of output: 221
🏁 Script executed:
#!/bin/bash
# Check if there's a setup file referenced in jest config
find ./src -name "*.js" -path "*/setup*" -o -name "setup*" | head -20Repository: ELEVATE-Project/mentoring
Length of output: 110
🏁 Script executed:
#!/bin/bash
# Read the setupFileAfterEnv.js to see the full matcher registration
cat -n src/setupFileAfterEnv.jsRepository: ELEVATE-Project/mentoring
Length of output: 1176
🏁 Script executed:
#!/bin/bash
# Check the integrationJest.config.js to see the full configuration
cat -n src/integrationJest.config.jsRepository: ELEVATE-Project/mentoring
Length of output: 1509
🏁 Script executed:
#!/bin/bash
# Check package.json for integration test scripts
rg "test.*integration|integration.*test" src/package.json -A 2 -B 2Repository: ELEVATE-Project/mentoring
Length of output: 544
🏁 Script executed:
#!/bin/bash
# Verify the exact filename in the integration-tests-new directory
find ./src/integration-tests-new -name "*.spec*.js" -type fRepository: ELEVATE-Project/mentoring
Length of output: 1682
🏁 Script executed:
#!/bin/bash
# Check how many .spec.js vs .specs.js files exist
echo "=== .spec.js files ===" && find ./src/integration-tests-new -name "*.spec.js" -type f | wc -l
echo "=== .specs.js files ===" && find ./src/integration-tests-new -name "*.specs.js" -type f | wc -lRepository: ELEVATE-Project/mentoring
Length of output: 121
Rename test file to match Jest config pattern or update testMatch in integrationJest.config.js.
The test file uses .spec.js but integrationJest.config.js expects *.specs.js (plural). This filename mismatch prevents Jest from discovering and executing this file under the integration test config, so setupFileAfterEnv.js never runs and toMatchSchema is unavailable.
The custom matcher is correctly registered via expect.extend(matchers) in setupFileAfterEnv.js, but it's only applied when the test file matches the testMatch pattern. Either rename feedback.spec.js to feedback.specs.js or update the pattern to **/*.spec*.js.
🤖 Prompt for AI Agents
In `@src/integration-tests-new/feedback/feedback.spec.js` at line 15, Rename the
test file or update Jest config so the integration tests load the setup file and
custom matcher; either rename feedback.spec.js to feedback.specs.js (so it
matches the existing integrationJest.config.js pattern) or modify
integrationJest.config.js testMatch to include **/*.spec*.js; ensure the file
using toMatchSchema remains named consistently and that setupFileAfterEnv.js
(which calls expect.extend(matchers)) is referenced by the same config so the
custom matcher toMatchSchema is registered at test runtime.
| adminDetails = await commonHelper.adminLogin() | ||
| let adminToken = adminDetails.token |
There was a problem hiding this comment.
adminDetails is not declared — implicit global variable.
adminDetails is assigned without let/const/var. This creates an implicit global, which will throw a ReferenceError in strict mode.
Proposed fix
- adminDetails = await commonHelper.adminLogin()
- let adminToken = adminDetails.token
+ const adminDetails = await commonHelper.adminLogin()
+ const adminToken = adminDetails.token📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| adminDetails = await commonHelper.adminLogin() | |
| let adminToken = adminDetails.token | |
| const adminDetails = await commonHelper.adminLogin() | |
| const adminToken = adminDetails.token |
🤖 Prompt for AI Agents
In `@src/integration-tests-new/mentees/mentees.specs.js` around lines 10 - 11, The
variable adminDetails is assigned without a declaration causing an implicit
global; change the assignment to declare it (e.g., use const or let) and
likewise declare adminToken; for example, replace the current lines with a
proper declaration like const adminDetails = await commonHelper.adminLogin() and
const adminToken = adminDetails.token or destructure with const { token:
adminToken } = await commonHelper.adminLogin() so both variables are
block-scoped.
|
|
||
| describe('GET /mentoring/v1/mentees/list', () => { | ||
| test('should return 200', async () => { | ||
| const url = `/mentoring/v1/mentees/list?page=1&limit=5&search=&connected_mentees=true&mentorId=${userDetails.id}` |
There was a problem hiding this comment.
userDetails.id is likely undefined — the login helper returns userId, not id.
Based on commonTests.js, the object returned by logIn() has userId (not id). This will interpolate as undefined in the query string, so the test won't exercise the intended code path.
Proposed fix
- const url = `/mentoring/v1/mentees/list?page=1&limit=5&search=&connected_mentees=true&mentorId=${userDetails.id}`
+ const url = `/mentoring/v1/mentees/list?page=1&limit=5&search=&connected_mentees=true&mentorId=${userDetails.userId}`📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| const url = `/mentoring/v1/mentees/list?page=1&limit=5&search=&connected_mentees=true&mentorId=${userDetails.id}` | |
| const url = `/mentoring/v1/mentees/list?page=1&limit=5&search=&connected_mentees=true&mentorId=${userDetails.userId}` |
🤖 Prompt for AI Agents
In `@src/integration-tests-new/mentees/mentees.specs.js` at line 105, The query
string uses userDetails.id but the login helper (logIn) returns userId, so
userDetails.id will be undefined; update the test to reference
userDetails.userId (or destructure userId from the result of logIn()) wherever
the mentorId is interpolated (the line building the url and any other places
using userDetails.id) so the correct userId is sent in the request.
| }) | ||
|
|
||
| test('should return 401/403 when unauthorized', async () => { | ||
| const url = `/mentoring/v1/mentees/list?page=1&limit=5&search=&connected_mentees=true&mentorId=${userDetails.id}` |
There was a problem hiding this comment.
Same userDetails.id → userDetails.userId issue here.
Proposed fix
- const url = `/mentoring/v1/mentees/list?page=1&limit=5&search=&connected_mentees=true&mentorId=${userDetails.id}`
+ const url = `/mentoring/v1/mentees/list?page=1&limit=5&search=&connected_mentees=true&mentorId=${userDetails.userId}`📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| const url = `/mentoring/v1/mentees/list?page=1&limit=5&search=&connected_mentees=true&mentorId=${userDetails.id}` | |
| const url = `/mentoring/v1/mentees/list?page=1&limit=5&search=&connected_mentees=true&mentorId=${userDetails.userId}` |
🤖 Prompt for AI Agents
In `@src/integration-tests-new/mentees/mentees.specs.js` at line 114, The test
constructs the request URL using the wrong property userDetails.id; update the
URL construction (the const url in the failing test) to use userDetails.userId
instead of userDetails.id so the mentorId query param is set to the correct
identifier; search for the const url declaration in the mentees.specs.js test
and replace the property reference accordingly.
| let req = request(BASE).post(url) | ||
| req = req | ||
| .set('x-auth-token', menteeDetails.token) // Use mentee's token | ||
| .set('org-id', menteeDetails.organizations[0]) // Correctly access the org ID string |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
# First, find commonTests.js and check how organizations is stored from login
fd -t f commonTests.js | head -5Repository: ELEVATE-Project/mentoring
Length of output: 146
🏁 Script executed:
# Search for where organizations is assigned from login responses
rg -n "organizations" --type=js -B2 -A2 | grep -E "(logIn|mentorLogIn|organizations)" | head -40Repository: ELEVATE-Project/mentoring
Length of output: 3872
🏁 Script executed:
# Look at the specific lines in requestSessions.specs.js
cat -n src/integration-tests-new/requestSessions/requestSessions.specs.js | sed -n '45,160p'Repository: ELEVATE-Project/mentoring
Length of output: 5308
🏁 Script executed:
# Check the user model or schema to understand organizations structure
fd -t f "user" -e js | xargs rg -l "organizations" | grep -E "(model|schema)" | head -5Repository: ELEVATE-Project/mentoring
Length of output: 105
🏁 Script executed:
# Check commonTests.js to see how logIn() and mentorLogIn() store organizations
cat -n src/integration-tests-new/commonTests.js | head -150Repository: ELEVATE-Project/mentoring
Length of output: 5792
🏁 Script executed:
# Look at userExtension.js model
cat -n src/database/models/userExtension.js | head -100Repository: ELEVATE-Project/mentoring
Length of output: 2828
🏁 Script executed:
# Check if there's a user model or schema that defines organizations
fd -t f "\.js$" -path "*/database/models/*" | head -10Repository: ELEVATE-Project/mentoring
Length of output: 237
🏁 Script executed:
# Search for where organizations is retrieved in login endpoints
rg -n "organizations" src/controllers/auth.js -B3 -A3 | head -60Repository: ELEVATE-Project/mentoring
Length of output: 132
🏁 Script executed:
# Search for where organizations is returned in login response
rg -n "\.organizations" src/controllers/ -B2 -A2 | head -80Repository: ELEVATE-Project/mentoring
Length of output: 1265
🏁 Script executed:
# Look for user serialization or response formatting
rg -n "result\.user" src/ --type js -B2 -A5 | head -100Repository: ELEVATE-Project/mentoring
Length of output: 6662
🏁 Script executed:
# Check the user model definition
fd -t f user.js | grep -E "models|schema"Repository: ELEVATE-Project/mentoring
Length of output: 51
🏁 Script executed:
# Search for organizations population in account/auth responses
rg -n "organizations" src/services/users.js -B3 -A3 | head -100Repository: ELEVATE-Project/mentoring
Length of output: 1579
🏁 Script executed:
# Find where the user object is populated in the login response
rg -n "result\.user" src/services/ --type js -B3 -A8 | head -150Repository: ELEVATE-Project/mentoring
Length of output: 51
🏁 Script executed:
# Search for account login or user login endpoints
fd -t f account.js -o auth.js | xargs cat -n | head -200Repository: ELEVATE-Project/mentoring
Length of output: 202
🏁 Script executed:
# Look for where res.body.result.user is set up
rg -n "user\:" src/ --type js -B2 -A5 | grep -A5 "organizations" | head -80Repository: ELEVATE-Project/mentoring
Length of output: 145
🏁 Script executed:
# Check the user controller for login response
rg -n "login|create" src/controllers/v1/user.js -A10 | head -150Repository: ELEVATE-Project/mentoring
Length of output: 135
🏁 Script executed:
# Find the user controller files
find src/controllers -name "*.js" -type f | head -20Repository: ELEVATE-Project/mentoring
Length of output: 718
🏁 Script executed:
# Search for account login in controllers
rg -n "login" src/controllers/v1/ -B2 -A15 | head -200Repository: ELEVATE-Project/mentoring
Length of output: 1185
🏁 Script executed:
# Check what user service returns
rg -n "formatUserResponse\|formatUser\|toJSON" src/ --type js -B2 -A10 | head -100Repository: ELEVATE-Project/mentoring
Length of output: 51
🏁 Script executed:
# Look directly at services/users.js for how organizations is handled
head -350 src/services/users.js | tail -200Repository: ELEVATE-Project/mentoring
Length of output: 6584
🏁 Script executed:
# Search for user-service or account microservice login endpoint
find src -name "*.js" -type f | xargs rg -l "account/login\|user.*login" | head -10Repository: ELEVATE-Project/mentoring
Length of output: 383
🏁 Script executed:
# Look for where the user object is assembled in response
rg -n "result\s*=" src/services/ --type js -A5 | grep -B3 -A3 "user\|organizations" | head -150Repository: ELEVATE-Project/mentoring
Length of output: 3084
🏁 Script executed:
# Check the userRequests module to see what user object structure comes from user-service
cat -n src/requests/user.js | head -250Repository: ELEVATE-Project/mentoring
Length of output: 10117
🏁 Script executed:
# Find where user.organizations is set
rg -n "user.organizations\|\.organizations\s*=" src/ --type js -B3 -A3 | head -120Repository: ELEVATE-Project/mentoring
Length of output: 51
🏁 Script executed:
# Look at where user login returns the organizations structure
rg -n "res.body.result.user" src/integration-tests-new/ -A5 | head -50Repository: ELEVATE-Project/mentoring
Length of output: 3570
🏁 Script executed:
# Check if there's a JSON response structure or schema documentation
find src -name "*.json" -type f | xargs rg -l "organizations" 2>/dev/null | head -5Repository: ELEVATE-Project/mentoring
Length of output: 174
🏁 Script executed:
# Final confirmation: Search for how org-id header is used elsewhere in tests
rg -n "org-id" src/integration-tests-new/ -B2 -A2 | head -80Repository: ELEVATE-Project/mentoring
Length of output: 7227
Fix inconsistent organizations access pattern—will send [object Object] as header value.
Lines 50 and 133 incorrectly access menteeDetails.organizations[0] as a primitive, while lines 93 and 155 correctly use mentorDetails.organizations[0].id.toString(). Since organizations is an array of objects (verified across all other test files), lines 50 and 133 will send the string representation of an object as the org-id header instead of the actual organization ID, causing test failures.
Change lines 50 and 133 to:
.set('org-id', menteeDetails.organizations[0].id.toString())
Also applies to: 93-93, 133-133, 155-155
🤖 Prompt for AI Agents
In `@src/integration-tests-new/requestSessions/requestSessions.specs.js` at line
50, The org-id header is being set with the whole object at the two mentee
sites; in src/integration-tests-new/requestSessions/requestSessions.specs.js
replace the incorrect uses of menteeDetails.organizations[0] when building the
request header with the actual org id string by accessing the id property and
converting to string (use menteeDetails.organizations[0].id.toString()); update
both occurrences that call .set('org-id', menteeDetails.organizations[0]) so
they match the correct pattern used for
mentorDetails.organizations[0].id.toString().
| const request = require('supertest') | ||
| const BASE = process.env.BASE_URL || 'http://localhost:3000' | ||
| const schemas = require('./schemas/role-extension.schemas.json') | ||
|
|
||
| describe('role-extension endpoints generated from api-doc.yaml', () => { | ||
| describe('POST /mentoring/v1/role-extension/create', () => { | ||
| test('should return 201', async () => { | ||
| const url = `/mentoring/v1/role-extension/create` | ||
| let req = request(BASE).post(url) | ||
| req = req.set('x-auth-token', 'bearer {{token}}') | ||
| req = req.set('x-auth-token', 'test-token') | ||
| req = req | ||
| .send({ | ||
| title: 'string', | ||
| label: 'string', | ||
| scope: 'string', | ||
| organization_id: 'string', | ||
| }) | ||
| .set('Content-Type', 'application/json') | ||
| const res = await req | ||
| expect(res.status).toBe(201) | ||
| // validate response schema | ||
| const schema = schemas['POST_mentoring_v1_role-extension_create'] | ||
| expect(res.body).toMatchSchema(schema) | ||
| }) | ||
|
|
||
| test('should return 401/403 when unauthorized', async () => { | ||
| const url = `/mentoring/v1/role-extension/create` | ||
| const res = await request(BASE).post(url) | ||
| expect([401, 403]).toContain(res.status) | ||
| }) | ||
|
|
||
| test('should return 400/422 for invalid body', async () => { | ||
| const url = `/mentoring/v1/role-extension/create` | ||
| let req = request(BASE).post(url) | ||
| req = req.set('x-auth-token', 'bearer {{token}}') | ||
| req = req.set('x-auth-token', 'test-token') | ||
| req = req.send({}).set('Content-Type', 'application/json') | ||
| const res = await req | ||
| expect([400, 422]).toContain(res.status) | ||
| }) | ||
| }) | ||
|
|
||
| describe('GET /mentoring/v1/role-extension/read', () => { | ||
| test('should return 200', async () => { | ||
| const url = `/mentoring/v1/role-extension/read?title=mentee` | ||
| let req = request(BASE).get(url) | ||
| req = req.set('x-auth-token', 'bearer {{token}}') | ||
| const res = await req | ||
| expect(res.status).toBe(200) | ||
| // validate response schema | ||
| const schema = schemas['GET_mentoring_v1_role-extension_read'] | ||
| expect(res.body).toMatchSchema(schema) | ||
| }) | ||
| }) | ||
|
|
||
| describe('POST /mentoring/v1/role-extension/update', () => { | ||
| test('should return 201', async () => { | ||
| const url = `/mentoring/v1/role-extension/update?title=mentee` | ||
| let req = request(BASE).post(url) | ||
| req = req.set('x-auth-token', 'bearer {{token}}') | ||
| req = req | ||
| .send({ | ||
| label: 'string', | ||
| scope: 'string', | ||
| organization_id: 'string', | ||
| }) | ||
| .set('Content-Type', 'application/json') | ||
| const res = await req | ||
| expect(res.status).toBe(201) | ||
| // validate response schema | ||
| const schema = schemas['POST_mentoring_v1_role-extension_update'] | ||
| expect(res.body).toMatchSchema(schema) | ||
| }) | ||
|
|
||
| test('should return 400/422 for invalid body', async () => { | ||
| const url = `/mentoring/v1/role-extension/update?title=mentee` | ||
| let req = request(BASE).post(url) | ||
| req = req.set('x-auth-token', 'bearer {{token}}') | ||
| req = req.send({}).set('Content-Type', 'application/json') | ||
| const res = await req | ||
| expect([400, 422]).toContain(res.status) | ||
| }) | ||
| }) | ||
|
|
||
| describe('DELETE /mentoring/v1/role-extension/delete', () => { | ||
| test('should return 200', async () => { | ||
| const url = `/mentoring/v1/role-extension/delete?title=mentee` | ||
| let req = request(BASE).delete(url) | ||
| req = req.set('x-auth-token', TOKEN) | ||
| const res = await req | ||
| expect(res.status).toBe(200) | ||
| // validate response schema | ||
| const schema = schemas['DELETE_mentoring_v1_role-extension_delete'] | ||
| expect(res.body).toMatchSchema(schema) | ||
| }) | ||
|
|
||
| test('should return 401/403 when unauthorized', async () => { | ||
| const url = `/mentoring/v1/role-extension/delete?title=mentee` | ||
| const res = await request(BASE).delete(url) | ||
| expect([401, 403]).toContain(res.status) | ||
| }) | ||
| }) | ||
| }) |
There was a problem hiding this comment.
Entire file uses placeholder auth tokens — no tests will pass authentication.
Like questions.spec.js, this file has no login setup (no commonHelper import, no beforeAll). Every test uses placeholder strings ('bearer {{token}}', 'test-token', or the undefined TOKEN). All tests expecting success status codes (201, 200) will receive 401/403 instead.
🤖 Prompt for AI Agents
In `@src/integration-tests-new/role-extension/role-extension.spec.js` around lines
1 - 104, The tests in role-extension.spec.js use placeholder/undefined auth
tokens (e.g., 'bearer {{token}}', 'test-token', TOKEN) so authenticated requests
will fail; fix by importing and using your test login helper (e.g.,
commonHelper.getAuthToken or commonHelper.login) in a beforeAll to obtain a real
token, store it in a module-level TOKEN variable, then replace the literal
headers (instances of 'bearer {{token}}', 'test-token', and the undefined TOKEN
usage) with req.set('x-auth-token', TOKEN) (or the correct header name/value
your helper returns); also remove duplicate req.set('x-auth-token', ...) calls
where present (see usages in POST /create, POST /update, GET /read, DELETE
/delete and the top-level TOKEN reference) so each request uses the real token
from beforeAll.
| let req = request(BASE).delete(url) | ||
| req = req.set('x-auth-token', TOKEN) | ||
| const res = await req |
There was a problem hiding this comment.
TOKEN is undefined — this will throw a ReferenceError at runtime.
TOKEN is never declared or imported anywhere in this file. This test will crash immediately when executed.
🐛 Suggested fix — use a proper auth token from login helpers
Import commonHelper, obtain a token in beforeAll, and reference it here. For example:
+const commonHelper = require('@commonTests')
+let adminDetails = null
+
+beforeAll(async () => {
+ adminDetails = await commonHelper.adminLogin()
+})
+
// ...
- req = req.set('x-auth-token', TOKEN)
+ req = req.set('x-auth-token', adminDetails.token)📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| let req = request(BASE).delete(url) | |
| req = req.set('x-auth-token', TOKEN) | |
| const res = await req | |
| const commonHelper = require('@commonTests') | |
| let adminDetails = null | |
| beforeAll(async () => { | |
| adminDetails = await commonHelper.adminLogin() | |
| }) | |
| // ... (rest of the code) | |
| let req = request(BASE).delete(url) | |
| req = req.set('x-auth-token', adminDetails.token) | |
| const res = await req |
🤖 Prompt for AI Agents
In `@src/integration-tests-new/role-extension/role-extension.spec.js` around lines
89 - 91, The test references TOKEN which is not declared, causing a
ReferenceError; fix by importing the login helper (e.g., commonHelper) and
obtaining an auth token in the test suite setup (beforeAll) and store it in a
variable used by this test; update the delete request code that uses
request(BASE).delete(url) to set the header with that token variable (replace
TOKEN with the setup token variable), ensuring the token is available to the
test that calls req.set('x-auth-token', ...).
| describe('rolePermissionMapping endpoints generated from api-doc.yaml', () => { | ||
| describe('POST /mentoring/v1/rolePermissionMapping/create/{role_id}', () => { | ||
| test('should return 201', async () => { | ||
| const url = `/mentoring/v1/rolePermissionMapping/create/{role_id}` |
There was a problem hiding this comment.
URL path parameter {role_id} is never substituted with an actual value.
The literal string {role_id} will be sent as part of the URL, which won't match any real route. Replace it with a valid role ID obtained from test setup.
Same issue on lines 24, 35, and 51.
🤖 Prompt for AI Agents
In
`@src/integration-tests-new/rolePermissionMapping/rolePermissionMapping.spec.js`
at line 8, The URL string uses the literal "{role_id}" instead of substituting
the actual role id; change the const url assignments (e.g., const url =
`/mentoring/v1/rolePermissionMapping/create/{role_id}`) to interpolate the real
role id (for example `const url =
\`/mentoring/v1/rolePermissionMapping/create/${roleId}\``) using the role id
produced by your test setup (e.g., createdRole.id or a roleId variable), and
make the same replacement for the other occurrences so the requests target the
real route and ensure the roleId variable is initialized before the URL is
built.
| test('should return 201', async () => { | ||
| const url = `/mentoring/v1/rolePermissionMapping/delete/{role_id}` | ||
| let req = request(BASE).post(url) | ||
| req = req.set('x-auth-token', TOKEN) |
There was a problem hiding this comment.
TOKEN is undefined — tests will crash with ReferenceError.
TOKEN is never declared or imported in this file. Lines 37 and 53 reference it. The first describe block uses 'string' (also a placeholder, but at least won't crash). Either obtain a real token via commonHelper.adminLogin() or use a consistent placeholder.
Proposed fix (minimal — still needs real auth for meaningful tests)
- req = req.set('x-auth-token', TOKEN)
+ req = req.set('x-auth-token', 'string')📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| req = req.set('x-auth-token', TOKEN) | |
| req = req.set('x-auth-token', 'string') |
🤖 Prompt for AI Agents
In
`@src/integration-tests-new/rolePermissionMapping/rolePermissionMapping.spec.js`
at line 37, The tests reference TOKEN (used in req.set('x-auth-token', TOKEN))
but TOKEN is not declared, causing a ReferenceError; replace the undefined TOKEN
by obtaining a real token via commonHelper.adminLogin() or by defining a
consistent placeholder token used across the file. Locate the failing usages
around the test suite (the req.set calls in the rolePermissionMapping.spec.js
tests) and either (a) call commonHelper.adminLogin() in a beforeAll/before hook
and assign the returned token to a module-scoped TOKEN variable, or (b) declare
a module-scoped const TOKEN = '<placeholder>' used by all tests; ensure any
async login is awaited and the variable is populated before tests run (e.g., set
TOKEN in beforeAll when using commonHelper.adminLogin()).
1 participant
Release Notes
CircleCI Pipeline Enhancement
Database & Schema Updates
Comprehensive Integration Test Suite
Configuration & Dependencies
Lines Changed by File
Contributors: Akash Shah, Joffin Joy, MallanagoudaB, Nevil Mathew, Priyanka Pradeep, Rocky, VISHNUDAS, adithya_dinesh, ankitpws, borkarsaish65, joffinjoy, prajwal, rakeshSgr, sumanvpacewisdom, tharununni, and others