Fix flaky e2e test

[PavelJankoski]

Summary

Fix flaky e2e test

Changes

• If the device is present for some application for some reason, we were getting 409 error. With this workaround we are not failing the test if a request gets 409.

Testing

Steps

Check CI if it turns green on every PR.

Results

The CI should turn green

Checklist

• Scope: The referenced issue is addressed, there are no unrelated changes.
• Compatibility: The changes are backwards compatible with existing API, storage, configuration and CLI, according to the compatibility commitments in README.md for the chosen target branch.
• Documentation: Relevant documentation is added or updated.
• Testing: The steps/process to test this feature are clearly explained including testing for regressions.
• Infrastructure: If infrastructural changes (e.g., new RPC, configuration) are needed, a separate issue is created in the infrastructural repositories.
• Changelog: Significant features, behavior changes, deprecations and fixes are added to CHANGELOG.md.
• Commits: Commit messages follow guidelines in CONTRIBUTING.md, there are no fixup commits left.

[ryaplots]

I am not sure this is the best solution, cause if we get 409 in this request for some other reason we won't know. @mjamescompton what do you think?

[mjamescompton]

Yeah if we don't fail on the 409, that would mean the device is not created correctly but we are hoping the tests don't require it to so it will pass.

What in the backend is causing the 409?

[PavelJankoski]

@ryaplots @mjamescompton It happens to return 409 Conflict when the device is already created (for some reason not deleted from some cluster with other tests, or when tests run in parallel i suppose) but in our case that doesn't matter. The only thing that matters in this test is that the device is present in the db.
Other solution is to create devices with random id's every time the test runs (with adding timestamp in the id for example)

[mjamescompton]

The only thing that matters in this test is that the device is present in the db.

Is this a failure of the test coverage that it does not matter if a device is incorrectly created.

for some reason not deleted from some cluster with other tests, or when tests run in parallel i suppose)

I would explore this more, why has it not been deleted yet. It might be an issue with the tests, it could be some caching within github actions, it could be a in issue with the backend. Try to explore how to fix this without editing the test but fix the underlying issue.

Other solution is to create devices with random id's every time the test runs (with adding timestamp in the id for example)

This could be an option if we can not find the underlying issue and could be the solutions if we need the test to run in parallel. How much work will this be and what are the negatives?

[mjamescompton]

@PavelJankoski, It indeed does seem like test will run in parallel

.github/workflows/console-e2e.yml

- name: Run frontend end-to-end tests
        uses: cypress-io/github-action@v6
        with:
          config-file: config/cypress.config.js
          config: baseUrl=https://thethings.localhost:8885
          record: true
          parallel: true <---- TEST RUN IN PARALLEL
          browser: chrome
          group: main-${{ needs.determine-if-required.outputs.hash }}
          spec: |
            **/*
            !cypress/e2e/smoke/smoke.spec.js
            ${{ steps.get-failed-spec.outputs.neg-failed-test }}

[PavelJankoski]

@mjamescompton @ryaplots I pushed the changes where I generate random device id when we create a device on all components.