Closing as Resolved since this doesn't seem actionable by the upstream without concrete reproducible steps.

/mail/ will tell you why you received any given mail.

We need to know how to reproduce bugs in order to fix them. Please take the time to give us all information needed about your environment so we can reproduce the bug. Id() missing means something is dramatically wrong with your installation, as no part of Phabricator is expected to run without access to libphutil and its functions.

For me seems to be quite good the information provided, but I try to explain myself with more details:

This report doesn't look to include reproduction information.

pcretest -C

PCRE version 8.10 2010-06-25
Compiled with

No UTF-8 support
No Unicode properties support
Newline sequence is LF
\R matches all Unicode newlines
Internal link size = 2
POSIX malloc threshold = 10
Default match limit = 10000000
Default recursion depth limit = 10000000
Match recursion uses stack

I open the debug mode, on console, i found errors:
preg_replace_callback(): Compilation failed: this version of PCRE is not compiled with PCRE_UTF8 support at offset 0
Stack trace:
preg_replace_callback called at [/lv_code/phabricator/phabricator/src/infrastructure/markup/rule/PhabricatorObjectRemarkupRule.php:189]
PhabricatorObjectRemarkupRule::apply called at [/lv_code/phabricator/libphutil/src/markup/engine/remarkup/blockrule/PhutilRemarkupBlockRule.php:78]
PhutilRemarkupBlockRule::applyRules called at [/lv_code/phabricator/libphutil/src/markup/engine/remarkup/blockrule/PhutilRemarkupDefaultBlockRule.php:17]
PhutilRemarkupDefaultBlockRule::markupText called at [/lv_code/phabricator/libphutil/src/markup/engine/PhutilRemarkupEngine.php:232]
PhutilRemarkupEngine::markupBlock called at [/lv_code/phabricator/libphutil/src/markup/engine/PhutilRemarkupEngine.php:128]
PhutilRemarkupEngine::preprocessText called at [/lv_code/phabricator/phabricator/src/infrastructure/markup/PhabricatorMarkupEngine.php:269]
PhabricatorMarkupEngine::loadPreprocessorCaches called at [/lv_code/phabricator/phabricator/src/infrastructure/markup/PhabricatorMarkupEngine.php:133]
PhabricatorMarkupEngine::process called at [/lv_code/phabricator/phabricator/src/infrastructure/markup/PhabricatorMarkupEngine.php:73]
PhabricatorMarkupEngine::renderOneObject called at [/lv_code/phabricator/phabricator/src/applications/phriction/controller/PhrictionMarkupPreviewController.php:23]
PhrictionMarkupPreviewController::processRequest called at [/lv_code/phabricator/phabricator/src/aphront/AphrontController.php:29]
AphrontController::handleRequest called at [/lv_code/phabricator/phabricator/src/aphront/configuration/AphrontApplicationConfiguration.php:257]
AphrontApplicationConfiguration::processRequest called at [/lv_code/phabricator/phabricator/src/aphront/configuration/AphrontApplicationConfiguration.php:169]
AphrontApplicationConfiguration::runHTTPRequest called at [/lv_code/phabricator/phabricator/webroot/index.php:17]

The policies work like you expect them to. This is just like a revision saying "All Users" but not being visible to users who can't see the corresponding repository.

I think it makes more sense to have events inherit their policy from the import that created them (if they are imported events)? i.e. rather than copy policy settings on import, make the policy pull from the import similar to other systems (like how "build target" view policy is pulled from the "build" view policy).

But yeah, it is 100% not good to show this:

Okay, so I ended up having to restart my Phabricator instance to get the import to stop, then "Delete Imported Events" seemed to work right even though it took a reasonably long time to complete from the web UI (I feel like it should really be using the bulk operation infrastructure).

Oh god it's still importing even after I disabled the import and deleted events.

It's just very
important to
thoroughly explore
the applications

In my case (T9287), the dependencies are cross-repository, which I don't think we can reasonably automatically figure out.

(If we were better about figuring this out automatically -- which we may be soon -- would it be a problem at all?)

In T11833#199387, @epriestley wrote:

The distinction between "Earlier Revisions" and "Earlier Versions of This Revision" (e.g., earlier diffs) seems potentially confusing to me. That is, I could imagine a new user thinking "Earlier Revisions" meant "earlier versions of this change", not "prior changes which this change depends on".

The distinction between "Earlier Revisions" and "Earlier Versions of This Revision" (e.g., earlier diffs) seems potentially confusing to me. That is, I could imagine a new user thinking "Earlier Revisions" meant "earlier versions of this change", not "prior changes which this change depends on".

"Earlier" / "Later" ?

Or, of course, we could do:

I think there was no web UI for this until T4788, which added both options. Prior to that, the only way to mark dependencies was by writing "Depends On" in text (which still works). So we didn't previously have anything else, unless I'm misremembering.

(I've asked a wordsmaster for help, so maybe we'll have better ideas soonish).

I was used to the "dependency" ones we had, but I agree they're not really unconfusing enough.

Our use of "parent" and "child" are consistent with Git's use of "parent" and "child", if that helps: for example, git help log discusses the ideas of "parent commits" and "child commits" in many places, and "parent revisions" and "child revisions" have the same relationship order as commits do in Git.

What specific, totally unambiguous labels would you prefer these actions to have?

The Phabricator versions you listed above are also not current. Just a reminder we only take bug reports at HEAD.

Bug reports like this are exceedingly resource intensive on the upstream and as stated, we are unlikely to look into for many years if ever. I'd be happy to accept this bug if you can duplicate the bug in a new, clean, environment and completely list out all components needed to reproduce it. Overall as no one else is reporting this, it is likely an environmental issue - so understanding what is unique in your environment vs everywhere else Phabricator is installed is important. Things to look at:

you can check this page, it is original phabricator page, it also cannot show in my server.
maybe the remarkup engine cannot work in my server, i don't know how to resolve it.

Could you tell me how to check the server error?
i don't find the errors on server.

Ah yea my hypothesis doesn't make 100% sense given all the rest of the text in your screenshot. Are there errors on the server?

i attached my saved webpage. The Text isn't existed the source code.

I don't know a thing about the web but looks like it might be a font issue. Presumably your setup has the monospaced font available for use in codeblocks, but not the regular text one.

I'll have to update my instance first to test your patch, since it seems to be for newer version as you said earlier. I installed this from FreeBSD ports system, have to first convert it to normal git based install.

Thanks for looking into the profile. The queuing I think fixes the issue with speed of importing. The next thing I was going to try was auto-import of the .ics file from a hosted location on hourly basis, and I'm assuming there's no proper way to only query for the newest things (at least though the API in Zimbra I've found) - so Phabricator would have to process the file every request. With queuing it shouldn't matter.

Here's the XHProf link:

This self-healed (probably after another commit was pushed) so I don't expect to look at it for a while unless it happens again.

At HEAD, I think the all-day issues with the French holidays above are fixed. You may need to reload the import for the change to take effect, but things seem OK for me locally now:

Ah, cool. I think that's a Zimbra issue, then.

I checked for that UID and there are exactly two events, both with "RECURRENCE-ID":

RECURRENCE-ID;TZID="America/New_York":20130528T150000

(mindrot.org is currently inaccessible for me so I wasn't able to read the details you linked, although I imagine they aren't too relevant to how we handle things.)

I was trying to import the french holidays from google ICS file...

This isn't a bug. Here's an example of why the proposed behavior is dangerous:

I'd prefer not to produce any output until we've generated everything, so we don't end up in a situation where we output half of the file and then fail if we can help it. Additionally, this script changed in D16744, a few weeks ahead of your version.

Thank you for clarifying the behavior of the timeout. It wasn't clear to me whether I would wait for feedback after clicking the Reload button or begin refreshing the page. After the change to queuing of import the events were imported. I'm doing all this testing on a test instance of Phabricator so I would be able to add log/debug statements and re-import the calendar again to track down what might be slow. The import pulled in ~1700 events in ~3 minutes.

I was trying to import the french holidays from google ICS file : https://calendar.google.com/calendar/ical/fr.french%23holiday%40group.v.calendar.google.com/public/basic.ics

I would expect that we could parse a 3MB .ics file in less than 30 seconds, but obviously there's nothing to prevent you from uploading a 30MB or 300MB or 3GB .ics file, and at some point we'll take longer than 30 seconds to process it.

I tried reloading the import again and still hit the 30 second timeout. There's no indication in the web page UI that anything happens but I checked the logs. Is this just expected for a large import?

T11399 has some discussion of "Location" for events -- we could possibly implement a little piece of that now to split out resources from normal attendees, but my initial inclination is to wait until we do a real implementation of locations.

If a user has a display name ("Meeting Room" <meetingroom@company.com>), we should show them as "Meeting Room", we just avoid showing meetingroom@company.com if that's the only name we have.

I think this is good default behavior and what I was expecting regarding not showing email address. My earlier comment was more about whether it could be shown as a Resource instead of an attendee (due to CUTYPE=RESOURCE;ROLE=NON-PARTICIPANT), or possibly the Location as the email matches what the LOCATION field is set as -- instead of "Private User" invitee. This sounds more like a new feature request and not a bug/issue - should I make a separate task?

I wasn't immediately able to reproduce the "OPT-PARTICIPANT" issue -- here's the file I used, trying to mimic your test case:

• D16804 should resolve the sha1() issue.
  • That may also resolve the timeout: the sha1() issue made us take a much slower code path. But I might also need to optimize the import and make it fall back to occurring in the background for large .ics files. Let me know if you're still seeing timeouts after the sha1() fix.
  • When a user is only an email address, we currently show "Private User 1" instead of the address. We could just show the address, or could show some "totally impossible to guess" address like me.......om@mycompany.com, but I wanted to err on the side of caution about disclosing email addresses, at least to start with. We're fairly conservative about this in other parts of the product and it's hard to put the cat back in the bag if we consider this information open. In Phabricator, it's easier to import an .ics file and expose the data to all users than it is in more private-by-default / personally-focused applications with defaults aimed more toward individual users, which also gives me some pause. But this may get in the way of usability too much, so I could see changing this behavior. If a user has a display name ("Meeting Room" <meetingroom@company.com>), we should show them as "Meeting Room", we just avoid showing meetingroom@company.com if that's the only name we have.
  • I'll look at the OPT-PARTICIPANT thing, I would expect them to import but just not have an "optional" marker right now. To clarify, they didn't import at all, right?
  • The "Ignored Node" stuff is likely fine, things like VALARM sections inside VEVENT sections. At some point I'll make the error message more helpful ("Ignored a VALARM section; Phabricator does not send reminders for imported events.") but probably OK to ignore those warnings for now.
  • URI stuff is because security.outbound-blacklist defaults to blacklisting all private/internal IP space, to prevent attackers from discovering and interacting with private services on your network by using features like image proxying, macros, calendar import, etc. If you want to fetch data from a host in private IP space, you'll need to remove its address from the blacklist (or expose an alternate interface for it in public IP space).

(Moved from T11816#199040)

2. Why is there a 2 in the middle of all that? https://xkcd.com/1530/

There's also a 6

Two questions come to mind.

As a workaround, the recommended value is 9999999999999999999999999999999999996999999999999999999999929999999999999.

Just encountered this problem on my setup too.

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.

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