404 error when reporting using Playwright + Azure DevOps CI pipeline

[jitterbox]

Created an Azure DevOps pipeline based on online docs, only major difference is that ours runs on Windows in a local agent pool, although I think we got the same result from a cloud-hosted Linux agent. Side note: Why is it giving a 404 rather than a 500 or some other error based on the actual issue? You provided the run ID and the base URL, it's confusing to make this a 404.

This is with @testomatio/reporter 2.0.1.
Confirmed that the Azure DevOps PAT has proper permissions.

Error reporting:

[TESTOMATIO] Provide this information:
Error: Request failed with status code 404

{
  body: '{"api_key":"xxxxxxxxxx","status_event":"fail"}',
  url: URL {
    href: 'https://app.testomat.io/api/reporter/71ffa85f',
    origin: 'https://app.testomat.io',/
    protocol: 'https:',
    username: '',
    password: '',
    host: 'app.testomat.io',
    hostname: 'app.testomat.io',
    port: '',
    pathname: '/api/reporter/71ffa85f',
    search: '',
    searchParams: URLSearchParams {},
    hash: ''
  },
  baseURL: 'https://app.testomat.io',/
  method: 'PUT',
  time: 'Tue, 08 Jul 2025 20:47:05 GMT'
}

[DavertMik]

Not enough information to reproduce

404 means that run probably not exists

[jitterbox]

@DavertMik But the run did exist, the Testomatio site provided the ID for use in the CI pipeline, unless the issue is with the server-side code that provided the run ID.
Consider trying a variation of this with a coding agent:

Context: I am investigating a possible bug in the @testomatio/reporter package. Users are reporting a Request failed with status code 404 error when the reporter attempts to update a run (PUT /api/reporter/:runId). The log shows the URL is correctly formed with a valid runId, yet the server returns 404. I suspect there may be a client-side issue with how the request promise is returned or how the 404 status is handled in the code.

Task: Review the codebase, specifically the file responsible for making HTTP requests (likely lib/client.js, lib/rest.js, or similar) and the function that handles updateRun or the PUT request to /api/reporter.

Please analyze the code for these two specific potential issues:

Return Mechanism Scoping:

Check if the axios.put (or equivalent) request is properly returned to the caller.

Look for broken promise chains: Is the request made inside a then() block, a callback, or a try/catch block where the return keyword is missing or improperly scoped?

Specific check: Does the function exit early (e.g., return;) in some cases without returning the Promise, potentially causing the calling function to proceed prematurely or fail to catch the subsequent error?

404 Return Logic & URL Construction:

Analyze how the runId is passed into the request. Is there any scenario (race condition or async timing) where runId could be undefined or null at the moment of execution, causing the URL to resolve to /api/reporter/ (which might 404)?

Check if the code attempts to "swallow" or handle 404s explicitly. Is there logic that might return a generic 404 error even if the root cause is different (e.g., a connection issue or auth failure masked as 404)?

Verify if the trailing slash handling in the URL construction could be causing a mismatch with the API endpoint.

Output: Point out the specific lines of code that handle the PUT request and the return logic. specific refactoring if you see any "floating promises" or unscoped return statements.

[olexandr13]

@jitterbox which testing framework do you use?
when do you send the specified request with failed event? at the end of testrun?
how much time tests execution takes?