Gah.

If it is impossible to reproduce this issue without writing custom code, we won't accept a patch for it.

I know that upstream can't offer support for fixing this, but would you be at all willing to accept a patch that addresses this issue?

I "fixed" this by deleting the data more aggressively and reloading the import. I couldn't reproduce this locally so I think it was a transient issue with an older import bug.

It seems that we're somehow importing events so they end up as their own parents.

That changed the stack trace but didn't fix the issue so I probably need to not cheat.

I can't reproduce this locally and I'm not really sure what's up (bad/weird import, maybe? But no issues importing the same source locally), so I'm just going to cheat my way through it at least for the moment.

Here's the trace:

I'm specifically interested in the arc diff --try part of this and would want that to be the configurable as the default behavior. For an installation that's using things like CircleCI integration to run tests asynchronously on a build server, it seems very plausible that reviewers will sometimes fail to notice that tests haven't finished running yet, which will lead to people landing broken code.

These are very much proof-of-concept for now, but should technically work after D16784. Expected behavior now:

Also interested in this. Our team plans on using the audit tool for code reviews, it be good if when a developer has made any suggested changes and re-committed that the old open audit could be closed/linked to the latest commit rather than having to comment on the old one with a link to the changed copy and just closing the old one manually.

Could phabricator.base-uri setting affect this? Our install is accessed via http://phab.domain.com:port/.

It may surprise us how much people use it.

I guess we're just accepting Calendar bugs in general now since I don't have a ton of known broken stuff left on my radar. I was aware of this one; D16777 should fix it.

I got 12 quest points. Level up!

I plan to start working on new comment/action UI here this week. Probably. Maybe.

Please be sure to update Phabricator before filing a bug report.

@rabahmeradi So it was, shortly afer reporting! Thanks.

Our users can confirm this behavior. With active persistent chat, the Lightbox is not working. If it is disabled, its working as expected.

Our users can confirm this behavior. With active persistent chat, the Lightbox is not working. If it is disabled, its working as expected.

In T11801#198622, @adam93 wrote:

Mentioned in chat but just to keep it logged. Importing an ics file with the following RRULE (RRULE:FREQ=WEEKLY;BYDAY=TH;INTERVAL=2) works as expected opening in Microsoft Outlook, but gives the following error in Phabricator upon import "RRULE INTERVAL "2" is invalid: interval must be an integer."

As @epriestley said in the general chat "We're missing an (int) cast in PhutilRecurrenceRule::newFromRRULE() on INTERVAL and probably COUNT".

Mentioned in chat but just to keep it logged. Importing an ics file with the following RRULE (RRULE:FREQ=WEEKLY;BYDAY=TH;INTERVAL=2) works as expected opening in Microsoft Outlook, but gives the following error in Phabricator upon import "RRULE INTERVAL "2" is invalid: interval must be an integer."

@indygreg - Thanks for reaching out and discussing a way forward. I am not on the phabricator team but I do have an interest in its integration capabilities with mercurial. At best I might be able to summarize my understanding of some of phabricator's needs based on the history of this task, but I do not feel I could properly represent them on mercurial's mailing-list or wiki. For hosting repositories I believe this task would require needing to know if the mercurial operation is read or write -- the two primary reasons being read/write access control and cluster picking.

Thanks for the suggestion but we have no current plans to un-prototype Phortune. Fork / patch as you need locally.

Duplicate thing filed in T11800.

I'm going to file the duplicate import thing as a separate task since it probably won't come up for a while and close this out.

While I'm hesitant to throw stones here and don't really have any context on bundle2 or the wire protocol in general and there may be plenty of reasons that it works like it does, my general impression is that the Mercurial wire protocol is significantly under-designed, and is now on at least the 3rd and possibly 4th iteration of hacks to try to address the lack of actual protocol design.

(Google API integration is covered by T2334 -- you can already interact with Google Calendar via ICS files, but that will add support for using the API instead.)

The Gmail/ICS integration seems to actually work OK in practice, here's an event from this install working (modulo some stuff like us not exporting a host/organizer yet):

I would subscribe to the Paste, and spend 20 seconds updating the file if it changes. Like I mentioned before, this task has already been prioritized and we're not going to work on it until other things in the prioritization queue have been completed. I think self-maintaining is a reasonable work-around.