OK, it seems utcInstanceEpoch is only used in child event of recurring events according to the code. After I canceled the recurring event(E4), there is no more error in phd log.

I just created a simple test event and the utcInstanceEpoch column is still NULL. What does this column mean?

just FYI, I checked the database and found the utcInstanceEpoch is NULL for some old events, which maybe caused by bug in data migration during upgrade.

T11036 will probably be the next round of changes, but I don't think we have this stuff on any immediate roadmap.

I think it's not perfectly clear in the UI, but we do have it documented:

That's up to you and your team.

In T12144#208351, @chad wrote:

I'd rather fix the core problem if it's an unclear typeahead.

I'd rather fix the core problem if it's an unclear typeahead.

My understanding is that subprojects are basically just regular projects but with a parent relationship. We didn't want these projects to pollute the projects typeahead because no-one should be creating tasks within these subprojects (given that these subprojects dictate what we are working on). By choosing "milestone" instead of "subproject", it becomes clearer in the project typeahead that the subproject is internal to the parent project. That is, if we made #our_january_goal a subproject then it would show up in the projects typeahead as "Our January Goal" whereas as a milestone it is rendered as "Our Team (Our January Goal)".

If the milestones aren't strictly ordered, why did the user create milestones instead of subprojects?

Awesome guys. I can confirm that this resolved the issue.

I think you can unlock yourself using the cli

I deployed this to the Phacility production cluster.

I'm going to merge this into T12142 since that one has an earlier timestamp even though this one is more pure of heart.

In T12143#208308, @chad wrote:

This is fixed on master and stable but hasn't rolled out to Phacility yet.

For the record, this is like the best, clearest bug report I've seen in months. :D

Are you filing this as a Phacility customer?

This is fixed on master and stable but hasn't rolled out to Phacility yet.

Ok I cherry-picked it, way easier than I expected.

I pushed this out to master and @epriestley will probably cherry-pick it to stable today.

Bisects back to D17235

Confirmed, we'll have a fix here shortly and probably cherry-pick to stable.

Erm… I was just asking for time repository update on the repository you have already cloned, hence the 15 seconds. If I understand this correctly, you seem to indicate that it would still be too much. I'm having a hard time understanding, but if you're adamant about this, then there is nothing left to say :)

I can repro on an instance upgraded at 20d1bb8fdf too. And indeed PhabricatorProjectWorkboardProfileMenuItem or PhabricatorProfileMenuItem classes don't contain a validateTransactions method.

I added some log in src/applications/calendar/storage/PhabricatorCalendarEvent.php before line 728 like this:

if ($this->isChildEvent()) {
      $parent = $this->getParentEvent();
      error_log("utc string:".$this->getUTCInstanceEpoch(),3,"/tmp/phadebug.log");
      $instance_datetime = PhutilCalendarAbsoluteDateTime::newFromEpoch(
        $this->getUTCInstanceEpoch());
      $recurrence_id = $instance_datetime->getISO8601();
      $rrule = null;
    }

It indicates $this->getUTCInstanceEpoch() returns empty or null. Any help for this? And I guess it should be related to some recurring events.

If you do find a way to reproduce the bug, please reply back and we'll look into it.

We'd be happy to help you further under Phacility Consulting services. We unfortunately do not take bug reports without reproduction steps or against prototype applications (Calendar).

No idea, I guess this is something related to the Calendar events in my install as you mentioned. I'm wondering if there is some place in the code I can add some lines to log/debug the actual event and the date/time string which caused the error? I can edit the source and run it again.

Thanks! Do you know how we can reproduce the error locally?

I'm still seeing this in the latest code:
phabricator

c63ba8337ec7e7f021f17c972e9a2a751f6280e2 (Sat, Jan 21)

arcanist

9503b941cc02be637d967bb50cfb25f852e071e4 (Sat, Jan 7)

phutil

6d8f5a783ebe7993b78632091507f6d7d8cbc215 (Sat, Jan 21)

Maybe someday this will be easier; https://lists.w3.org/Archives/Public/www-style/2016Mar/0370.html

I'll get back to you

Well

I think the pros and cons are something like:

oh man these crack me up.

Haha, sorry I think this might be a good JS learning side project for me on the weekends if I have free time.

I think we should just use actual emoji for this, not sprite sheets?

In D17238#205025, @epriestley wrote:

Yep, go for it.

If this is a bug report, please see Contributing Bug Reports and fill out all required information. If this is a feature request, please see Contributing Feature Requests. If you need support for your account here on secure, please just use General Chat or contact@phacility.com.

I deployed that change here (secure.phabricator.com). I'll cherry-pick it and deploy it on admin in a little bit, if nothing catches on explosion fire.

Haha, no worries. Uninstalling Home is pretty unusual.

ugh. sorry

After purging dead instances, db003 and db004 are each <25% utilized on their data volumes.

Purging db001 brought primary volume down to 79.2%, which is technically below the 80% caution threshold. It doesn't need to be fixed immediately, but the pathway forward isn't terribly clear. Some options are:

Instance service windows on db003 and db004 have synchronized and the shards are now purging.

The temporary directory storage pressure on repo016 has an unclear root cause (it's related to importing an SVN repository, but I haven't been able to pinpoint where the issue started). The issue no longer appears to be occurring so I'm going to stop digging until it happens again.

The storage pressure on db001 is primarily because an instance imported a large SVN repository with approximately 60M paths. The instance is a free instance with one user.

The db001, db003 and db004 shards have also hit 80% full on their primary volumes. I'm purging dead instances from db001 now. db003 and db004 have never been purged and need to have instance out-of-service dates synchronized first. This is currently underway for db004.

I'm going to move forward with the deploy since this shouldn't impact actual instances, the stuff in this menu isn't super-critical, and workarounds (albeit inconvenient ones) exist to access the items.

And if I gave you a precise estimate you could be sneaky and just divide it by $1,500/hr to get the answer without paying for it!

Obviously, we can't just hand out estimates for free. Converting units and multiplying numbers together takes away valuable time and resources we could be using to develop Phabricator.

What'd be the fee for that 1 second command and a 5 second copy/paste?

I'll make sure to update this task with full reproduction steps on Monday.

I appreciate the details and pointers - we may look at a custom reject transaction and/or required action bucket. I just went digging here for related discussion to see if others may have run across similar scenarios.

If you miss a comment and then forget about a revision you authored for a while, it probably wasn't that critical?

I can investigate further what issues people are having with the current solutions - I'm not sure being critical is the concern but more-so there being a delay for the change to land/verify without it being clear who should be the next step (presumably from the dashboard/bucket?).

I'd be happy to, see Consulting to move forward.

How do I reproduce unexpected results at the application level (for example, what's something I can search for that doesn't match but should match)?

Yes and no. So: maybe?

Could you at least give me the time output for the broken/test repository update on your test system, so that I have a baseline for comparison later? Thanks!

I want to resist adding additional actions here if they would be rarely used and reasonable workarounds already exist. After EditEngine (T11114), third-party extensions will also be able to provide supplemental actions.

In T12136#208145, @chad wrote:

I can vanish them now.

I can vanish them now.

Yeah I meant to clean that up too

While I've got you, how do you feel about a diff to:

(If there's pushback, maybe like a "one-time hacky copy your old global app settings into the menu script that we don't support" sort of thing? But I'd guess users won't feel like this is too painful since the new menu is a lot more flexible/powerful.)

I think it would potentially be reasonable to not migrate, especially if you do another blog post like the Favorites one to ease migration pain. Global stuff is relatively recent and pretty easy to put back in place, and I think a gentle nudge to configure the menu to work well for your install isn't a bad thing.