Thanks for that catch in D17651, let me know if you're still seeing issues after updating. I'll cherry-pick that to stable too.

Yeah, that looks like it's consistent with the hypothesis above. I expect:

Not sure if this is useful:

Yeah, pretty sure what's happening is:

See also T12532 for related work.

I think the first error is causing (maybe?) the chunk engine to fail, so we're falling back to the "upload the entire file in one shot" engine, which ain't great on 4GB files.

Alright, let me take a look. That exception is pretty specific and it may be obvious from the code.

Hmm, I got a different error with a 9MB file. But this looks like a problem on our end:

I originally tried a 1GB file and wasn't able to reproduce...

(Actually maybe you need a 9MB file.)

Does this reproduce with a 5MB file?

From the server-side error logs:

Okay, I managed to reproduce it with non-sensitive data:

A SAAS install reported bumping into this.

Does the language in D17648 look OK?

Do you routinely schedule events in timezones other than UTC or your local time? If so, why? (For example, do you frequently travel between two timezones? Do you schedule events on behalf of a team that works in a different, non-UTC timezone?)

The address is verified but the verified flag on your account is not set.

I think this is, to at least some degree, a legitimate security problem. Consider:

• After D17646, event reminder mail should render with timezone information.
• Additionally, timezone information in this mail and other modern ModularTransactions mail will now render with timezone abbreviations where available: (PDT) instead of (UTC-7), for example.
• I wasn't able to identify or reproduce any actual bug here. Hopefully the additional information in D17646 will make it clear what's happening. The expectation is that the mail you receive should use the same locale as your account uses in Settings → Date and Time → Timezone, and in all my local attempts to reproduce this that was the case. Note that if an event is scheduled in UTC but instances cross daylight savings time in a particular locale the local time of the event may change. I don't think that's what happened here, just mentioning it. See also T11073.

I think this is a legitimate bug where the viewer's timezone on the event becomes stuck as the last invitee we process, so events with multiple invitees in different timezones can generate mail with the last user's timezone.

Go ahead and create a new request -- knowing which things people actually want/use will be helpful since other calendaring applications seem to have very complex controls here without much consistency and with different supported sets of capabilities.

Future instances of recurring events aren't visible in panels when an item limit is set:

I'm just trying to understand whether this is a common problem that all users of Calendar software routinely experience, or a problem that is experienced much more strongly at WMF that by most other users.

This is her status at 13:45 today...
She doesn't have any events till 14:00 today.

I believe this occurs only if an install has improperly migrated legacy data. This install does; presumably yours does as well.

@ivo, I'll follow up for this on T12488 which appears to be a similar standalone report:

@EddieGP, see T11073.

ICS issues seem to have calmed down so I'm going to call this resolved; future issues can just be filed as separate tasks.

This is technically possible (and I believe imported events do have some support for mutation within Phabricator today: for example, I believe you can award them tokens). However, I'm very hesitant to start making imported events writable.

We ultimately built an "ngram index" for this task, see T9979 for discussion.

• T11586 has context.
• D16541 added PHUIInvisibleCharacterView and has usage examples.
• Go hunt down as many error messages which include user input in a validation error as you can find/test and wrap them in PHUIInvisibleCharacterView. The task description lists some. I don't think there's any systematic way to find these, and we shouldn't expect to be exhaustive.
• Close this when satisfied / bored / everything else is too much of a pain to test.
• Primary goal here is just an onboarding goal of poking around some different applications, we haven't really seen users hit this stuff.

• When you click "Delete File", we currently delete the file in the web process. Since we've supported enormous files and pluggable storage backends for a while, this could take an arbitrarily long amount of time to complete.
  • Instead, we want to flag the file as "deleted", hide it in the web UI, and queue up a task in the daemons to actually get rid of the data.

Actually, this will probably take longer to provide guidance for than to implement.

This is now possible with edge.search.