missing Atom feed cache invalidating after adding link

[mro]

The 0.5.* versions until current master seem to have a cache invalidation bug after adding a new link.

See https://github.com/mro/Shaarli-API-test/issues/1#issuecomment-138123795

See all failing builds under so called 'allowed failures* in https://travis-ci.org/mro/Shaarli-API-test/builds/79034284

[virtualtam]

The test script is too fast emitting requests.

Per #238 the 2 default links are created:

• using the current date minus 1 minute for the private link
• using the current date YYYYMMDD_HHmmSS for the public link

The POST request is very likely to entail the creation of a new link with the same timestamp as the default public link, thus overwrites it when saving.

I've forked the API tester and added sleep s between requests: https://travis-ci.org/virtualtam/Shaarli-API-test/builds/79055902

[virtualtam]

Relates to #137 - batch "add multiple links" feature

[mro]

The test script is too fast emitting requests.

There is no such thing as a too fast when it comes to computers.

[mro]

@virtualtam awesome finding by the way.

[mro]

closing as the PR #348 has all there is to know.

[virtualtam]

There is no such thing as a too fast when it comes to computers.

Sadly, there is quite often when dealing with external (web) services - one must cope with their limitations (processing time, responsivity, server load) to simulate interactions accordingly.

The issue here is a Shaarli limitation due to not storing links with a fine-enough-grained timestamp. Changing this is possible but not likely, as it would certainly wreak havoc on users' datastores.

[nodiscc]

The issue here is a Shaarli limitation due to not storing links with a fine-enough-grained timestamp. Changing this is possible but not likely, as it would certainly wreak havoc on users' datastores.

If ever a non backwards-compatible version of Shaarli is worked on, should timestamps be precise down to the millisecond?

Right now two links saved at the same second will result in colliding shortlinks. This affects links created in an automated way (tests), and will likely affect batch-created links (#137) unless there's a built-in workaround. Manually creating links will likely never be an issue unless you're a very fast clicker.

Related #348 (comment)

[mro]

@nodiscc would such a change really imply breaking backward-compatibility?

[virtualtam]

The link datastore is represented as an associative array, where a link is accessed by using its timestamp as a key.

Changing this would mean:

• changing the way links are stored and accessed (new format)
• handling two data formats and/or a datastore migration for all Shaarli users

Until having a clean enough codebase, there is a very high risk we (developers) may miss use cases in doing so, thus break everyone's Shaarli instance.

[mro]

I understand it would be a large change. And risky with scarce test coverage, but
@virtualtam why would such break backward-compatibility?