new activitypub test: create-then-update-modifies-object-checked-by-get

2024-02-05

I published a first draft of a new test in activitypub-testing.

Its slug is create-then-update-modifies-object-checked-by-get.

The test tries to find evidence that an ActivityPub outbox conforms to this requirement that

The side effect of [the Update activity] is that the object MUST be modified to reflect the new structure as defined in the update activity, assuming the actor has permission to update this object.

To do this, it tries to

1. POST outbox with a Create to create an object
2. fetch the result of that to determine the object id
3. POST outbox with an Update to update the object with that id
4. fetch the object by id
5. expect the object to reflect modifications from the Update activity submitted earlier

This is the simplest test I could come up with. It will work for some implementations, and not for others. It's not meant to be the only way to satisfy the requirement, just a first way.

Of note is that it may take some time for the outbox server to process the Update request such that it is reflected in the response to the request in step 4. It is important for scalability and resilience reasons to find ways of tolerating a delay in this processing.

On the SWICG testing task force call last week, someone (Marcus R?) rightly noted that one thing that's tricky in ActivityPub interop (and, I'd add, in any distributed system), is knowing when another party is done reacting to a message you've sent them. In the future, maybe there will be FEPs that describe ways for the actor or other sender of an activity to be 'called back' with lifecycle events of various processors of that activity.

Until then (and I'm not holding my breath 😅), this test isn't going to do anything fancy. If desired, maybe it can have a polling timeout configured by an input and be willing to wait up to that configured amount of time to find the modified object. There may be value in having this test case be simple and only apply to instances with great read-after-write consistency, and have other test rules that apply for other behaviors of servers that have more eventual consistency. It will be useful to identify which servers those are by running this test on them.

You can read the code for the test case on codeberg.org.

(remember, this is a first draft and RFC. it may change and is not the only way to test the requirement.)

In other news, it's been very rainy in San Francisco these last couple days. And when that happens ants invade my apartment and crawl up the wall by my desk as I hack. But a perk of the rain it there was time to finish a good book 📚, watch a PBC doc on fractals 🌳 and this morning I saw a rainbow 🌈 while walking by the Bay, and that was nice.