Rescuing a stuck story

Somehow we've managed to get a story onto desk with no
workflow (I think).

If I try to check it out from the desk I get:

Can't call method "checkout" on an undefined value
at
/data/bricsites/bricolage/lib/Bric/App/Callback/Desk.pm line
65, <GEN1156>
line 75.

When I search for it I see the story in the list but it has
no checkout
options and is not indicated as being checked out to anyone
else.

How can I get this back straight ?

I think what happened was this:

1. User went to do checkin and publish
2. System checked story into auto-publish desk (we have two
publish desks
   and this stage usually ends up picking auto-publish and
not publish)
3. System tries to publish story but it fails due to some
dependency on
   another story (manually thrown by the templates)
4. Meanwhile, auto-publisher runs (from cron), sees story
and publishes it
   and removes it from the workflow.
5. System reverts story to the Sub desk

The logs show some of this but not all of it, which is
consistent with
this kind of rollback, *but*, I thought all this was in a
transaction and
the rows should be locked to prevent this kind of race
condition.

Any ideas ?

Simon Wilcox

-- 
Digital Craftsmen Ltd
Exmouth House, 3 Pine Street, bond. EC1R 0JH
t 020 7183 1410 f 020 7099 5140 m 07951 758698
w http://www.digitalcr
aftsmen.net/

> Somehow we've managed to get a story onto desk with no
workflow (I think).
>
> If I try to check it out from the desk I get:
>
> Can't call method "checkout" on an undefined
value at
> /data/bricsites/bricolage/lib/Bric/App/Callback/Desk.pm
line 65, <GEN1156>
> line 75.
>
> When I search for it I see the story in the list but it
has no checkout
> options and is not indicated as being checked out to
anyone else.
>
> How can I get this back straight ?
>
> I think what happened was this:
>
> 1. User went to do checkin and publish
> 2. System checked story into auto-publish desk (we have
two publish desks
>   and this stage usually ends up picking auto-publish
and not publish)
> 3. System tries to publish story but it fails due to
some dependency on
>   another story (manually thrown by the templates)
> 4. Meanwhile, auto-publisher runs (from cron), sees
story and publishes it
>   and removes it from the workflow.
> 5. System reverts story to the Sub desk
>
> The logs show some of this but not all of it, which is
consistent with
> this kind of rollback, *but*, I thought all this was in
a transaction and
> the rows should be locked to prevent this kind of race
condition.
>
> Any ideas ?
>
> Simon Wilcox

We've had good luck using bric_soap to check out the story
when this 
happens:

bric_soap workflow checkout  --server http://bric/  story_4557

Then it should appear in your workspace.

John

Sorry for being so late to the party on this thread, but
we've just 
started experiencing the same thing, where a story's info in
the 
database gets corrupted.  Does anyone know what causes
stories to get 
into the bad state?  Is this something that needs a bug
report filed?

Thanks,

Matt

>On Tue, 5 Dec 2006, johngrumpet.net wrote:
>>>Somehow we've managed to get a story onto desk
with no workflow (I think).
>>>
>>>If I try to check it out from the desk I get:
>>>
>>>Can't call method "checkout" on an
undefined value at
>>>/data/bricsites/bricolage/lib/Bric/App/Callback/
Desk.pm line 65, <GEN1156>
>>>line 75.
>>>
>>>When I search for it I see the story in the list
but it has no checkout
>>>options and is not indicated as being checked
out to anyone else.
>>>
>>>How can I get this back straight ?
>>>
>>>I think what happened was this:
>>>
>>>1. User went to do checkin and publish
>>>2. System checked story into auto-publish desk
(we have two publish desks
>>>   and this stage usually ends up picking
auto-publish and not publish)
>>>3. System tries to publish story but it fails
due to some dependency on
>>>   another story (manually thrown by the
templates)
>>>4. Meanwhile, auto-publisher runs (from cron),
sees story and publishes it
>>>   and removes it from the workflow.
>>>5. System reverts story to the Sub desk
>>>
>>>The logs show some of this but not all of it,
which is consistent with
>>>this kind of rollback, *but*, I thought all this
was in a transaction and
>>>the rows should be locked to prevent this kind
of race condition.
>>>
>>>Any ideas ?
>>>
>>>Simon Wilcox
>>
>>We've had good luck using bric_soap to check out the
story when this happens:
>>
>>bric_soap workflow checkout  --server http://bric/  story_4557
>>
>>Then it should appear in your workspace.
>
>If that doesn't work, I usually check in:
>story
>  * usr__id, workflow__id, desk__id
>  - story_instance   (story__id = story.id)
>    * checked_out
>  - story_member     (object_id = story.id)
>member              (id = story_member.member__id)
>  - grp              (id = member.grp__id)
>  * member.grp__id is a desk?
>
>Compare with a story that's in a good state,
>SQL until it seems to be fixed.


-- 
Matt Rolf, J.D.
Web Technology Analyst
Computing Services
Denison University
(740) 587-6537

I don't know why it happens. It hasn't happened for me since
last  
spring. It seems to have happened when I was republishing
the whole  
site using bric_soap while another user checked out and
republished  
the home page.

At the time, the story publishing of a story template
triggered the  
republishing of the home page, however now I set a condition
in my  
story template that checks how old the story is and only
republishes  
the home page if the story is less than a month old.

I could paste that code for you if you like.

But really-stories shouldn't get shoved into workflow limbo
like  
this. But I don't know enough about the guts of bricolage to
suggest  
how to stop it.

Dawn

On 1-Mar-07, at 11:31 AM, Matt Rolf wrote:

> Sorry for being so late to the party on this thread,
but we've just  
> started experiencing the same thing, where a story's
info in the  
> database gets corrupted.  Does anyone know what causes
stories to  
> get into the bad state?  Is this something that needs a
bug report  
> filed?
>
> Thanks,
>
> Matt
>
>> On Tue, 5 Dec 2006, johngrumpet.net wrote:
>>>> Somehow we've managed to get a story onto
desk with no workflow  
>>>> (I think).
>>>>
>>>> If I try to check it out from the desk I
get:
>>>>
>>>> Can't call method "checkout" on
an undefined value at
>>>>
/data/bricsites/bricolage/lib/Bric/App/Callback/Desk.pm line
65,  
>>>> <GEN1156>
>>>> line 75.
>>>>
>>>> When I search for it I see the story in the
list but it has no  
>>>> checkout
>>>> options and is not indicated as being
checked out to anyone else.
>>>>
>>>> How can I get this back straight ?
>>>>
>>>> I think what happened was this:
>>>>
>>>> 1. User went to do checkin and publish
>>>> 2. System checked story into auto-publish
desk (we have two  
>>>> publish desks
>>>>   and this stage usually ends up picking
auto-publish and not  
>>>> publish)
>>>> 3. System tries to publish story but it
fails due to some  
>>>> dependency on
>>>>   another story (manually thrown by the
templates)
>>>> 4. Meanwhile, auto-publisher runs (from
cron), sees story and  
>>>> publishes it
>>>>   and removes it from the workflow.
>>>> 5. System reverts story to the Sub desk
>>>>
>>>> The logs show some of this but not all of
it, which is  
>>>> consistent with
>>>> this kind of rollback, *but*, I thought all
this was in a  
>>>> transaction and
>>>> the rows should be locked to prevent this
kind of race condition.
>>>>
>>>> Any ideas ?
>>>>
>>>> Simon Wilcox
>>>
>>> We've had good luck using bric_soap to check
out the story when  
>>> this happens:
>>>
>>> bric_soap workflow checkout  --server http://bric/  story_4557
>>>
>>> Then it should appear in your workspace.
>>
>> If that doesn't work, I usually check in:
>> story
>>  * usr__id, workflow__id, desk__id
>>  - story_instance   (story__id = story.id)
>>    * checked_out
>>  - story_member     (object_id = story.id)
>> member              (id = story_member.member__id)
>>  - grp              (id = member.grp__id)
>>  * member.grp__id is a desk?
>>
>> Compare with a story that's in a good state,
>> SQL until it seems to be fixed.
>
>
> -- 
> Matt Rolf, J.D.
> Web Technology Analyst
> Computing Services
> Denison University
> (740) 587-6537
>

On Mar 1, 2007, at 11:31, Matt Rolf wrote:

> Sorry for being so late to the party on this thread,
but we've just  
> started experiencing the same thing, where a story's
info in the  
> database gets corrupted.  Does anyone know what causes
stories to  
> get into the bad state?  Is this something that needs a
bug report  
> filed?

It has been reported a number of times. It usually happens
because  
the current version of a story gets published while someone
checks it  
out. We've added a number of ways to deal with this, most  
significantly the 'published_version' parameter to
Story->list(). Use  
it when you're looking up stories in templates to republish
(e.g.,  
when the publication of a story triggers a republication of
the home  
page). You should also use it when you republish via
bric_soap (-- 
search 'published_version=1').

Best,

David

We've also noticed that when our administrators check out
stories 
into the workflow of a different site than the story is in,
then 
cancel the check out, it becomes hard to predict when
searching for 
that story will allow other users to see and check it out. 
Perhaps a 
different issue.

>On Mar 1, 2007, at 11:31, Matt Rolf wrote:
>
>>Sorry for being so late to the party on this thread,
but we've just 
>>started experiencing the same thing, where a story's
info in the 
>>database gets corrupted.  Does anyone know what
causes stories to 
>>get into the bad state?  Is this something that
needs a bug report 
>>filed?
>
>It has been reported a number of times. It usually
happens because 
>the current version of a story gets published while
someone checks 
>it out. We've added a number of ways to deal with this,
most 
>significantly the 'published_version' parameter to
Story->list(). 
>Use it when you're looking up stories in templates to
republish 
>(e.g., when the publication of a story triggers a
republication of 
>the home page). You should also use it when you
republish via 
>bric_soap (--search 'published_version=1').
>
>Best,
>
>David


-- 
Matt Rolf, J.D.
Web Technology Analyst
Computing Services
Denison University
(740) 587-6537

On Mar 1, 2007, at 12:41, Matt Rolf wrote:

> We've also noticed that when our administrators check
out stories  
> into the workflow of a different site than the story is
in, then  
> cancel the check out, it becomes hard to predict when
searching for  
> that story will allow other users to see and check it
out.  Perhaps  
> a different issue.

Yes, it sounds like it. IF you could report that with
instructions  
for how to recreate it, I'd very much appreciate it.

Best,

David

We are working on it.

>On Mar 1, 2007, at 12:41, Matt Rolf wrote:
>
>>We've also noticed that when our administrators
check out stories 
>>into the workflow of a different site than the story
is in, then 
>>cancel the check out, it becomes hard to predict
when searching for 
>>that story will allow other users to see and check
it out.  Perhaps 
>>a different issue.
>
>Yes, it sounds like it. IF you could report that with
instructions 
>for how to recreate it, I'd very much appreciate it.
>
>Best,
>
>David


-- 
Matt Rolf, J.D.
Web Technology Analyst
Computing Services
Denison University
(740) 587-6537