add test for resolving users with aliases

[hughrun]

Description

Adds a test to ensure resolving remote IDs when a user has an alsoKnownAs entry is resolved properly.

In #3426 I thought there was a problem, but this test shows that there is not. So I think what I was seeing is when the remote id can't be reached.

• Related Issue #
  Closes activitypub.resolve_remote_id throws IntegrityError if remote user has unknown alias #3426

What type of Pull Request is this?

• Bug Fix
• Enhancement
• Plumbing / Internals / Dependencies
• Refactor

Does this PR change settings or dependencies, or break something?

• This PR changes or adds default settings, configuration, or .env values
• This PR changes or adds dependencies
• This PR introduces other breaking changes

Details of breaking or configuration changes (if any of above checked)

Documentation

• New or amended documentation will be required if this PR is merged
• I have created a matching pull request in the Documentation repository
• I intend to create a matching pull request in the Documentation repository after this PR is merged

Tests

• My changes do not need new tests
• All tests I have added are passing
• I have written tests but need help to make them pass
• I have not written tests and need help to write them

[hughrun]

LOL well I guess all the failing tests kind of prove the point.

Will fix this in a bit.

[mouse-reeve]

This is failing in main (it looks like the test is correctly finding that the alias is created incorrectly). I guess what I'm wondering is why it passes here?

[hughrun]

Hmm, I suspect this might be because we're running tests concurrently (pytest -n 3), and I guess which ones happen to still be running together is slightly different between the two branches?

Within test_base_activity we do indeed create 4 users, because we test to see if the default server user is created in one test, but with sequential tests that wouldn't be a problem because each test is supposed to be isolated.

@mouse-reeve using the --dist=loadfile flag and value in our pytest runner might help: it makes sure tests within each test file are all assigned to the same worker.

[hughrun]

Actually thinking about this more, it's probably because main includes the change I made so that all requests are signed, which will force the creation of the server representative user?

I'll see if I can work this out locally and push a fix if possible.

[mouse-reeve]

Yes I think that’s it - I was able to recreate the test failure locally running single threaded and I introspected on the user list and iirc the instance user was there so it all checks out