UI: Jobs requested with the wrong namespace under the right conditions

[DingoEatingFuzz]

When a namespace is set in localStorage and a job with the namespace default is requested, the default namespace gets overridden by the namespace in localStorage.

Example:
{ id: 'my-job', namespace: 'default' } gets requested as
/v1/job/my-job?namespace=ns-in-local-storage

Since the jobs routes set the local storage namespace before fetching any data, the only places this could occur were on clients and allocations. The easiest way to reproduce this bug is:

1. Change namespaces to something other than default
2. Reload the page to ensure the localStorage param is being used from the beginning of the app's life
3. Visit the clients page.
4. Visit individual clients.
5. Observe allocations with "..." as their job/task-group.

Note that namespaces are an enterprise feature so this ui bug only impacted enterprise deployments.

[johncowen]

👍 Cool, I had a click around everywhere and couldn't see any ...'s whereas I could on master. Couple of minor things:

1. Your 'unit' tests seem to be testing much more than a single isolated unit, are these more integration tests?
2. Might be a good candidate for acceptance tests also?

Actually this has just given me a thought on how I can do some of my PR's better

[DingoEatingFuzz]

Your 'unit' tests seem to be testing much more than a single isolated unit, are these more integration tests?

The job adapter tests started out as unit tests I swear 🙂Just the job adapter itself has grown more and more interdependent. It's the most highly relational model, it extends watchable, and it has namespace voodoo that depends on the system service (which in turn depends on localStorage and the namespaces model/serializer/adapter).

I suppose you're right, it's about time to call this what it is.

Might be a good candidate for acceptance tests also?

Yeah, that'd be good. Basically visit the client page for a client with allocations in the default namespace and assert that the correct requests are made. It doesn't add a lot of coverage per se, but it's nice to have something that's a little more e2e.

[johncowen]

hehe yeah I know the type!

For acceptance stuff, I was thinking for myself for stuff like this, I might split the failing test off into the first commit of the branch so people can easily see it breaking first, then any commits after that are to fix it. That way its easy to get an idea of what you are looking at whilst you folks are reviewing. I think it would be good for these little bugfix issues, maybe not the bigger features tho.

Might do that on my next one, see if it helps.

[DingoEatingFuzz]

Yeah, TDD is great for bug fixes. Some day I'll practice what I preach 🙈

[johncowen]

😄

I think its more putting the test and the fix in separate commits, I've pretty much been bundling it all up together in the same commit. If the breaking test was in a different commit to the fix it might be helpful for you folks to easily see what its fixing whilst reviewing?

[DingoEatingFuzz]

Maybe? I usually skim the commit messages so it could. If Github had a diff view equivalent of git log -p --reverse it would help more.

[github-actions]

I'm going to lock this pull request because it has been closed for 120 days ⏳. This helps our maintainers find and focus on the active contributions.
If you have found a problem that seems related to this change, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.