LunaticChat.git/platform-paper, branch main

fix(deps): update dependency io.papermc.paper:paper-api to v26.2.build.112-stable (#280)

2026-08-11T11:54:14+00:00

Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>

fix(deps): update dependency io.papermc.paper:paper-api to v26.2.build.111-stable (#277)

2026-08-07T17:54:33+00:00

Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>

fix(deps): update dependency io.papermc.paper:paper-api to v26.2.build.107-stable (#275)

2026-08-07T14:09:23+00:00

Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>

fix(deps): update dependency io.papermc.paper:paper-api to v26.2.build.105-stable (#274)

2026-08-07T09:56:31+00:00

Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>

fix(deps): update dependency io.papermc.paper:paper-api to v26.2.build.100-stable (#272)

2026-08-07T05:28:01+00:00

Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>

fix(deps): update dependency io.papermc.paper:paper-api to v26.2.build.98-stable (#271)

2026-08-05T23:41:36+00:00

Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>

fix(deps): update dependency io.papermc.paper:paper-api to v26.2.build.96-stable (#270)

2026-08-05T17:56:45+00:00

Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>

fix(deps): update dependency io.papermc.paper:paper-api to v26.2.build.93-stable (#269)

2026-08-05T14:05:44+00:00

Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>

test: cover what the player settings store promises

2026-08-04T19:26:57+00:00

It was the one file store without a test, so the round trip it exists for - and
its two fallbacks, an absent file and an unparseable one - were only asserted
through PlayerSettingsManager. The write failure matters most: loading a torn
file discards every player's settings, so a failed save must leave the previous
file untouched.

Co-Authored-By: Claude

fix: stop a slow reply from pinning a word to hiragana

2026-08-04T18:45:52+00:00

Making a conversion timeout an ordinary exception put it in the same arm as a
hard API failure, where caching the hiragana fallback is deliberate - so one slow
reply recorded the unconverted form and that word rendered as hiragana for the
life of the cache. A timeout says the request was slow, not that the word has no
conversion, so it now returns the fallback without caching it and the next
message asks again.

The retry test builds its own remembering cache: the shared fixture's get()
always returns null, so against it the API is called every time and the test
would have passed even with the timeout cached.

Co-Authored-By: Claude