Summary
The reference implementation v3.5.0 was published and plans were made to improve the wikidata bot.
Tasks
GitLab
While working on the GitLab driver, it was discovered that user deletion may be subject to long delays. The compliance suite was modified to cope with this behavior. Not just for GitLab but also other forges that may be in the same case.
Asynchronous behavior
The 3.5.0 of the F3 reference implementation has better support for asynchronous behavior. It is not uncommon, for instance, that opening a pull request on a remote forge using the API returns success immediately but it takes a little while before the API can be used to query the pull request that is supposedly already created.
When a software relies on F3 to perform an operation on a forge, it must be presented with an API that either succeeds or fails. It is inconvenient when the caller needs to account for transient failures that require a retry. Although idempotency allows the caller to just retry a few times, this is an unnecessary burden when such a logic can be implemented at a lower level.
Wikidata updates
The script to build the Forge matrix must be modified to cope with long delays in the Wikidata test infrastructure. tests.wikidata.org is the only way to create fixtures to test the bot against wikidata. Unfortunately:
- it is severely throttled (currently around 10 seconds between requests)
- it is flaky
The consequences are:
- very long delay when running tests
- breakage during days or even weeks while the issue is fixed
- even longer delays (5 minutes for an item to be indexed currently) on some cases
The proposed solution is to capture the test.wikidata.org requests and make it possible to replay them (offline mode) instead of using the actual tests.wikidata.org (live mode).
Plans for the next month
- Publish the first release of the specifications
- Improve the coverage Heptapod driver
- Use the F3 CLI, as a standalone tool or embedded in Forgejo, to continue the debug loop that integrates user feedback