fix(AppDisableListener): pass full provider key to deleteProvider - #265
Conversation
AppDisableListener passed the bare provider id (e.g. "mail") instead of the full provider key appId__providerId (e.g. "mail__mail") to ActionScheduler::deleteProvider(). The backend rejects the bare id (is_valid_provider_id / ^[a-zA-Z0-9_-]+__[a-zA-Z0-9_-]+$), and because it validates the whole ActionsQueueItems batch in one model_validate() call, this single poisoned row makes updates_processing_thread throw on every poll and freezes the entire oc_context_chat_action_queue indefinitely. The correct full key is already available in $key, so pass it directly. Also document in ActionScheduler::deleteProvider() that the full appId__providerId key is expected. Fixes nextcloud#258 Signed-off-by: weltmaister <55494283+weltmaister@users.noreply.github.com>
485ec28 to
6bc4101
Compare
|
Hello there, We hope that the review process is going smooth and is helpful for you. We want to ensure your pull request is reviewed to your satisfaction. If you have a moment, our community management team would very much appreciate your feedback on your experience with this PR review process. Your feedback is valuable to us as we continuously strive to improve our community developer experience. Please take a moment to complete our short survey by clicking on the following link: https://cloud.nextcloud.com/apps/forms/s/i9Ago4EQRZ7TWxjfmeEpPkf6 Thank you for contributing to Nextcloud and we hope to hear from you soon! (If you believe you should not receive this message, you can add yourself to the blocklist.) |
2 participants
Summary
AppDisableListenerschedules adelete_provider_idaction using the bare provider id (e.g.mail) instead of the full provider keyappId__providerId(e.g.mail__mail). The backend rejects the bare id (is_valid_provider_id,^[a-zA-Z0-9_-]+__[a-zA-Z0-9_-]+$).Because
context_chat_backend'supdates_processing_threadvalidates the wholeActionsQueueItemsbatch in a singlemodel_validate()call, this one invalid item makes it throw on every poll and freezes the entireoc_context_chat_action_queueindefinitely — access-declaration updates, deletions, etc. stop propagating and it never recovers on its own.Details in #258.
Fix
$keyalready holds the correct full key (appId__providerId), so pass it directly toActionScheduler::deleteProvider()instead of the split-off$providerId.Also documented on
ActionScheduler::deleteProvider()that it expects the fullappId__providerIdkey (as returned byProviderConfigService::getConfigKey()), matching every other caller.Trigger / impact
AppDisableEventfires whenever an app that registered a content provider is disabled — including during app updates /occ upgrade. The Mail app registers provider idmail, so each disable produced one poisoneddelete_provider_id: mailrow. Observed effect: 500+update_access_decl_source_idactions stuck for ~1 day; ACL/share changes not reflected in semantic search until the poison rows were removed manually.Note
Secondary hardening —
updates_processing_threadvalidating/skipping per item (like the files path already does viaItemValidationError) instead of aborting the whole batch — belongs incontext_chat_backendand is out of scope here.