fediverse-devnet / feditest

A testing framework for distributed, heterogeneous systems communicating with complex protocols, such as the Fediverse
https://feditest.org/
MIT License
33 stars 6 forks source link

WordPress Node: version problems #284

Closed steve-bate closed 4 weeks ago

steve-bate commented 2 months ago

The WordPress version for my installation is "WordPress/6.6.1". This doesn't work with Mastodon.py without some special configuration. It looks like Mastodon.py supports explicitly specifying a Mastodon version or setting version_check_mode to "none", which might have other side effects. This could potentially be done on a per Node subclass basis.

Related-ish: #282


As a side note, the version format also prevents me from adding the server to my iOS IceCubes client app. I've seen the same issue with my own Masto API implementation if I didn't use something that looked like a Mastodon version string. I wouldn't be surprised if this affects other client apps too since they often use the Mastodon version to know what features are available.

image

jernst commented 2 months ago

Have you reported this to the plugin project and/or mastodon.py? Seems that is something they should consider sorting out ...

steve-bate commented 2 months ago

It's not a mastodon.py issue since it supports a version check opt-out. What's not clear to me yet is if this opt-out is global or per api instance. Mastodon will not work without the API version check and WordPress won't work with it, so we need an api-level configuration. Currently, I'm seeing this configs conflict with each other, but I don't know if that's because of the way the api instances are being created or not..

This also isn't a WordPress issue because there's no restrictions on the Mastodon version string format.

One could argue that it's an issue with specific client applications, but if those applications need to know the presence or not of specific features (like whether whether /api/v1/search or /api/v2/search are available), they don't have much choice than to determine that based on the Mastodon version.

jernst commented 2 months ago

So what's the next step here?

steve-bate commented 2 months ago

This is my suggestion:

  1. Get the existing test_mastodon_node.py tests to run with the latest node redesign. I think it would be best if you do this.
  2. After that, I can extend the node tests so they can be run against both Mastodon and WordPress instances (probably failing initially because of issues in the list).
  3. After we have a running node unit test suite, we can use that to investigate making changes to how we're creating the mastodon.py instances and whether it's possible to make the version check opt-out on a specific api instance. I'm sure there will be some way to do it, even if it requires some "monkey patching".
jernst commented 1 month ago

Blocked by #308

steve-bate commented 1 month ago

Aren't we deleting the unit tests referred to in #308 in favor of the new feditest integration self-tests?

jernst commented 1 month ago

In your three-bullet list up there, with #355 we are now done with 1. and 2. Can you work on number 3?