I've just opened:
https://bugzilla.osafoundation.org/show_bug.cgi?id=12312
Problems occur when Chandler Desktop users publish the Sharing
Activity collection. Besides being kinda a weird thing to publish,
there's a behavior where backslashes in items in that collection get
doubled each time the collection syncs. This has caused some items on
Chandler Hub to have bodies of 8Mb.
The real production issue is that the 8Mb bodies have broken the
ability to create standard MySQL backups of Chandler Hub. I
originally assumed someone just published a big item and was going to
bump a parameter to allow larger backups but then I found the
backslash-doubling problem. Pasting Grant's description of how the
backslash problem originates:
-----
When you sync, a NoteRecord gets added to that collection, containing
basically the log file text for the sync.
That log file text contains quotes (the theory is you could
paste it into a python interpreter)
But, because we then go and sync that collection, we add a
NoteRecord (for the original sync).
That NoteRecord will quote one extra level (so as to
reproduce the singly quoted text we sent to the server)
That new NoteRecord will then get synced to the server next
time around
And so we will create a new NoteRecord in Sharing Activity,
which will have one extra level of syncing
-----
So basically the root cause is Chandler escaping backslashes in log
files coupled with Sharing Activity log entries being posted to
Sharing Activity itself.
I'm experimenting now with ways to protect the Hub from (or fix, at
least) these situations. We could talk about fixing Chandler Desktop,
but since we can't force 1.0 clients to upgrade (except by blocking
all 1.0 clients), I'd like to develop a manual (and automatable)
procedure as a first step.
A few options for a fix are listed in the bug above. There's a couple
of Desktop-oriented fixes, there's a cronjob fix maybe (forgot to list
that one), or possibly we could block Cosmo from accepting any
collections named "Sharing Activity".
My first priority is to restore the ability to perform Hub backups.
If deleting collections on the server-side works without Chandler just
republishing, it seems reasonable to just delete the collection for
the problematic user(s) without warning (and probably a followup
email); I really don't think anyone is relying on this. It seems
people probably just published "everything" when they went through a
publish step.
-- Jared
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
