Mailing List Archive

Hi Nick,

I've seen it on and off for years, but I still can't offer a
hard-and-fast method for reproducing it.

I suspect you're right that it's somehow related to the issue outlined
in that thread.

There are a lot of different flavours of stuck story:

1. An attempt to check in fails because a record (with checked_out =
false) already exists in story_instance for the version that Bricolage
is attempting to create. This one gives a database constraint error.
(Basically, whatever created the record in story_instance failed partway
through, so did not increment the current_version field in the story
table.)

2. A story vanishes from the UI, even though it has not been deleted.
(In this case, the current_version field in the story table is one
larger than the largest value in story_instance. Which looks like the
complete opposite of error #1.)

3. An attempt to check out fails because a record (with checked_out =
true) already exists in story_instance for the current version of the
story. Also a fair bit like error #1.

4. The error you mentioned. usr__id in story is not null, but no record
in story_instance has a true checked_out field.

5. A cover story stops updating itself, even though a simple call to
publish_another() should be triggering it regularly. Here's what's
happening:

* The cover story should be found using a $story->list().

* The list() call passes a false value for the "checked_out" parameter.

* Somewhere in story_instance, an old version of that cover story has a
true value for the checked_out field.

* This old version prevents the list() from including that cover in the
list it returns, even though it is not the current version.

* So the cover does not get published.

In this case, sometimes there will be two records for the old version,
with one checked out and one not, in which case the fix is to delete the
checked_out record. If there is only one record for that version,
setting its checked_out field to false does the trick.


That's a lot of kinds of stuck stories, and I'm sorry to have so little
insight into what causes them. In general, though, the following factors
seem to be involved:

1. Multiple processes attempting to publish the same item at once,
especially SOAP vs. the UI.
2. Stories whose templates use the API to edit other stories.
3. Misbehaving editorial staff who have two UI windows open, with both
logged in as the same user.


The real trick is reproducing the errors reliably, which I've never
managed to do. Does any of what I've typed above suggest anything to
try?


Cheers,

Bret




On Fri, 2011-05-27 at 09:32 -0400, Nick Legg wrote:
> Hi all,
>
> From time to time a story in our system becomes "stuck" in a
> partially-checked out state where the story_instance entries are all
> checked in (according to the database) but the story entry itself still
> has a usr_id set. At this point, the story does not appear on the
> Workspace of whomever supposedly has it checked out; it also reported as
> checked out when searching for it in a Workflow. Whenever this occurs,
> I see the following error in the error_log:
>
> [Fri May 27 12:58:53 2011] [error] [client 140.141.6.5] Cannot checkin
> non checked out versions, referer:
> https://freestyle.denison.edu/workflow/profile/story/31307
> [/usr/local/bricolage/lib/Bric/Biz/Asset.pm:1738]
> [/usr/local/bricolage/lib/Bric/App/Callback/Profile/Story.pm:152]
> [/usr/local/share/perl5/Params/CallbackRequest.pm:296]
> [/usr/local/share/perl5/MasonX/Interp/WithCallbacks.pm:119]
> [/usr/local/share/perl5/HTML/Mason/ApacheHandler.pm:868]
> [/usr/local/share/perl5/HTML/Mason/ApacheHandler.pm:822]
> [/usr/local/bricolage/lib/Bric/App/Handler.pm:308]
> [-e:0]
>
> Has anyone seen this before? Any ideas what might cause this?
>
> This is similar to the issue reported at
> http://www.gossamer-threads.com/lists/bricolage/users/9696?search_string=stuck;#9696
> and may or may not be related.
>
> Thanks,
> Nick
>

--
Bret Dawson
Producer
Pectopah Productions Inc.
(416) 895-7635
bret@pectopah.com
www.pectopah.com

Hi Bret,

Thanks for that detailed write-up. I have experienced most of those
different flavors of stuck stories before, but the cause was always a
mystery. This time, however, I am suspecting some browser shenanigans.
Strange things tend to happen in Bric 2's AJAX-y interface when a user's
browser crashes or otherwise halts rendering the page and/or executing
its JavaScript (try pressing the stop button while loading a large story
with several WYSIWYG fields). These things are, of course, extremely
difficult to track down. I'll be in touch if I can get something
reproducible.

Thanks,
Nick

On 5/27/2011 10:44 AM, Bret Dawson wrote:
> Hi Nick,
>
> I've seen it on and off for years, but I still can't offer a
> hard-and-fast method for reproducing it.
>
> I suspect you're right that it's somehow related to the issue outlined
> in that thread.
>
> There are a lot of different flavours of stuck story:
>
> 1. An attempt to check in fails because a record (with checked_out =
> false) already exists in story_instance for the version that Bricolage
> is attempting to create. This one gives a database constraint error.
> (Basically, whatever created the record in story_instance failed partway
> through, so did not increment the current_version field in the story
> table.)
>
> 2. A story vanishes from the UI, even though it has not been deleted.
> (In this case, the current_version field in the story table is one
> larger than the largest value in story_instance. Which looks like the
> complete opposite of error #1.)
>
> 3. An attempt to check out fails because a record (with checked_out =
> true) already exists in story_instance for the current version of the
> story. Also a fair bit like error #1.
>
> 4. The error you mentioned. usr__id in story is not null, but no record
> in story_instance has a true checked_out field.
>
> 5. A cover story stops updating itself, even though a simple call to
> publish_another() should be triggering it regularly. Here's what's
> happening:
>
> * The cover story should be found using a $story->list().
>
> * The list() call passes a false value for the "checked_out" parameter.
>
> * Somewhere in story_instance, an old version of that cover story has a
> true value for the checked_out field.
>
> * This old version prevents the list() from including that cover in the
> list it returns, even though it is not the current version.
>
> * So the cover does not get published.
>
> In this case, sometimes there will be two records for the old version,
> with one checked out and one not, in which case the fix is to delete the
> checked_out record. If there is only one record for that version,
> setting its checked_out field to false does the trick.
>
>
> That's a lot of kinds of stuck stories, and I'm sorry to have so little
> insight into what causes them. In general, though, the following factors
> seem to be involved:
>
> 1. Multiple processes attempting to publish the same item at once,
> especially SOAP vs. the UI.
> 2. Stories whose templates use the API to edit other stories.
> 3. Misbehaving editorial staff who have two UI windows open, with both
> logged in as the same user.
>
>
> The real trick is reproducing the errors reliably, which I've never
> managed to do. Does any of what I've typed above suggest anything to
> try?
>
>
> Cheers,
>
> Bret
>
>
>
>
> On Fri, 2011-05-27 at 09:32 -0400, Nick Legg wrote:
>> Hi all,
>>
>> From time to time a story in our system becomes "stuck" in a
>> partially-checked out state where the story_instance entries are all
>> checked in (according to the database) but the story entry itself still
>> has a usr_id set. At this point, the story does not appear on the
>> Workspace of whomever supposedly has it checked out; it also reported as
>> checked out when searching for it in a Workflow. Whenever this occurs,
>> I see the following error in the error_log:
>>
>> [Fri May 27 12:58:53 2011] [error] [client 140.141.6.5] Cannot checkin
>> non checked out versions, referer:
>> https://freestyle.denison.edu/workflow/profile/story/31307
>> [/usr/local/bricolage/lib/Bric/Biz/Asset.pm:1738]
>> [/usr/local/bricolage/lib/Bric/App/Callback/Profile/Story.pm:152]
>> [/usr/local/share/perl5/Params/CallbackRequest.pm:296]
>> [/usr/local/share/perl5/MasonX/Interp/WithCallbacks.pm:119]
>> [/usr/local/share/perl5/HTML/Mason/ApacheHandler.pm:868]
>> [/usr/local/share/perl5/HTML/Mason/ApacheHandler.pm:822]
>> [/usr/local/bricolage/lib/Bric/App/Handler.pm:308]
>> [-e:0]
>>
>> Has anyone seen this before? Any ideas what might cause this?
>>
>> This is similar to the issue reported at
>> http://www.gossamer-threads.com/lists/bricolage/users/9696?search_string=stuck;#9696
>> and may or may not be related.
>>
>> Thanks,
>> Nick
>>