R CMD check is red on main: shinychat now refuses chat$clear() when history is enabled #324

R CMD check is failing on main with one test error:

Error ('test-chat.R:63:7'): commons_server queues a restore reminder when history is restored
Error in `chat$clear()`: Can't clear a chat with conversation history enabled. Use `chat$new_chat()` to start a new conversation.

CI resolves shinychat from r-universe (shinychat_0.4.0.9000_dde163e) rather than a pinned version, so a development build changed under us.

shinychat #399 ("Add new_chat for conversation history"), commit dde163e, merged 2026-09-08 and added new_chat() along with a guard at the top of client_clear() in pkg-r/R/chat_app.R: when a history controller exists, clear() now aborts instead of clearing.

In commons, shinychat::chat_server() defaults to history = TRUE, and commons_server() calls it without passing history (pkg-r/R/chat.R:116), so there is no configuration reachable through commons in which clear() still works. clear() is not deprecated, it is closed off for the only setup this package creates. This needs a decision about the test rather than a rename.

The test uses clear() at line 63 to assert that the pending restore reminder is dropped, then separately asserts the same thing through controller$new_chat() two lines later.

Deciding what the test should assert is an R behavior question. The options look like:

• exercise the clear path with history disabled, since that is now the only configuration where clear() is reachable
• or drop the clear() assertion because new_chat() already covers the same commons behaviour
• or keep asserting that commons drops the reminder and accept that upstream now owns which method gets there.

It's also worth a decision whether commons CI should pin the shinychat build it resolves, given upstream changes can cause CI failures unexpectedly (like this one).

@simonpcouch @cpsievert any thoughts?