Could you point out whats wrong with the event, just so we know what to expect.

Yep, it was the Apache restart. Sorry for poor testing, thanks for fixing the incidentally discovered bug, and hopefully the other part of my comment was less useless :)

I did find D14574 in testing this, so there was at least 1 bug.

These errors point to being behind HEAD and/or not restarting Apache/PHP-FPM. rP2a063a for example resolved the constant issue.

master as of yesterday (Tue) approx. 2 pm PST. When I get home I'll check if the logs match up, but I took care to pull all three repos and ran a storage upgrade.

Are you at HEAD?

Not opening another bug report since Phame is not out of beta yet, but I thought I should still let you know that I stumbled upon an exception yesterday after updating from before the comments revamp:

• When viewing a Blog page (not a post itself): (Unable to resolve method 'isArchived'.)
• When submitting a New Blog form: >>> UNRECOVERABLE FATAL ERROR <<< Undefined class constant &#039;TYPE_STATUS&#039;

Fixed in HEAD (D14571).

Some more information:

Haha, no problem. Definitely not a big deal either way.

also, sorry. I should have been more clear.

aargh.. ok. shouldn't be a big deal though; I am pretty sure we will pay. The hard part is not the budget.

Ah, okay, I wasn't sure if "cool!" meant "approved" or "I'll look into it".

awesome! thanks! you weren't kidding about 15mins :)

cool! thanks!

I can give you an extension for this in about 15 minutes (at consulting rates).

I am interested in getting an estimate

Monsieur @epriestley can go over that, if you're interested.

This might be an easier thing to prioritze and pay for (even as an extension). Is there a way to get an estimate?

You can also speak to the powers that be and formally prioritize T7617 also.

It's not simpler to build, and then replace, a system. We don't build software in that manner.

@chad I figured this would be a simpler and less disruptive task, so filed it separately. The other task still doesn't have any consensus on whether we want to do something and if then what. I was hoping this could get faster consensus.

Oh that was the task I was looking for before making this one.

How does this relate to T5879?

You can't currently examine the most-recently-applied set of transactions, although we could reasonably pass them down and expose them.

I'd like to remove this event, because (a) it doesn't work right and never has and (b) all use cases we've seen are better suited to either Herald or mechanisms covered in T5462.

Not sure... Can we check old and new value in Herald? In event listener one of the checks is to compare old and new value in transaction to detect team change (custom field).

Can you do that with Herald instead?

Auto-assignment for example.

What does the logic in your listener do?

Thanks! Should be fixed in HEAD.

If you look at the error message and the path you can see what the issue is:

Is this different than T4921?

lastest cpplint + arcanist HEAD (9e78d15) still have this issue, using @tyhoff's regex fix the issue.

The way I'm getting around this now is I added a Herald rule "Commit message does not contain [experimental]". Then when pushing to non-master branches we add "[experimental]" to the commit message. When we want to put it on master, we squash and amend to remove the text and then push.

Yeah, I'd really like to just get rid of this option. It's definitely not something we'd accept upstream today.

Nothing every goes wrong with lots of options!

Sorry about the delay... here's the trace from running /bin/storage upgrade --namespace testT9773_$RANDOM --force --no-adjust --trace:

Gah, details of the Herald transcript have already been garbage collected.

Out pf curiosity, why not use the @{article:...} syntax instead of copy-pasting the full URL?

We haven't seen other installs encounter difficulty here. T5055 will eventually build some flavor of first-party package manager which should address a large superset of this problem class.

D14523 possibly describes a cleaner fix for this (special case autoloads when class_exists() is on the stack).

Who does the transcript show as the "Reviewer" for the change?

This is intentional, consistent, documented, etc.

Confirming that removing the apostrophe from the slug in the db did resolve. Thanks.

No one else can reproduce this. storage upgrade --trace ... might provide some insight, or add --xprofile to that or whatever. We can look at it in more detail if you can narrow it down more.