[Chandler-dev] Problems sharing Sharing Activity collection

Jared Rhine jared at wordzoo.com
Fri Aug 15 16:12:29 PDT 2008


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





More information about the chandler-dev mailing list