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.

I don't know what this means. $ in the string contents isn't anything special for translatewiki.net.

The technical definition of "Limited" is that it has fewer than 512 strings, including 0 strings.

You should file a new bug report, describing exactly what you did and how we can reproduce the problem.

To report a bug, please provide complete reproduction steps. We can't fix issues we can't reproduce. See Contributing Bug Reports for details.

I think D16810 should get this started, at least. Known technical issues:

@MZMcBride, couple of questions so we can improve this:

I've marked D16806 as resolving this. Once that lands, here's the state of the world in terms of how the product works:

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.

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.

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).

Cool. I'll merge this into T4124 and retitle that to be a little more specific.

We've only seen that one other time, so it hasn't been a priority to fix. I believe the other install which hit the issue was able to install GNU diff to resolve it.

Incidentally, this Phabricator installation is running on Solaris (Solaris 11.3) if that makes any difference.

(If you believe I'm mistaken, please show the full stack trace for the error so we can identify and remove the remaining reference to this column.)

@deric, the code event.dateTo no longer appears anywhere in Phabricator (it was removed prior to the column being removed) so I suspect you did not restart properly and were running cached code (or possibly have custom code you need to update). See Restarting Phabricator.

• D16803 should fix Applications → Calendar → Edit Policies.
• D16800 + D16801 should fix fanciful timezones present in ICS files.
• D16802 should add the ability to select a greater or lesser degree of away-ness for each event.

These shards are now in service.

Provisioning completed, now deploying.

Starting this now.

Yeah, test on master -- there's a ton of stuff fixed there that's still broken on stable.

Today, we already decode the SSH wire protocol and figure out what's going on inside it up to the bundle2 stuff -- here's the, uh, "protocol spec":

I've rotated the certificates on lb, alb, and notify. One minor notify issue that I'll file separately.

As a workaround, the recommended value is 9999999999999999999999999999999999996999999999999999999999929999999999999.

I'm just going to WONTFIX this for now since Maniphest and Differential don't show descriptions either and it's not clear to me that event descriptions are significantly more valuable than task/revision/etc descriptions. Open to changing this, but we should either change it everywhere or have some consistent rule for when they do/don't show.

I can't reproduce this by following the steps provided. Here's what I did:

This appears to legitimately be fixed, now.

I finally got this reproducing locally, at least.

Gah.

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

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: