Please put your version information on all bug reports. There has been a lot of churn here so we need to know you're at HEAD before trying to reproduce.

Thanks, closing this one!

You should have sweeping janitorial powers as a member of Community now.

Or I guess, you* can close this since I can't. Whoops.

Scratch that, you're right @epriestley . We just got confused during the workflow and didn't realize jmeador previously accepted.

Whoops, I think I may have totally fudged the screenshots. Let me try to reproduce with proper screenshots.

It looks like before step (2), jmeador can only accept for one reviewer (the package), since he's already accepted for himself. The current rule is:

This seems to have fixed the issue. Thanks for the quick fix.

T12531: Unable to upload file: failed to read 4583864320 bytes after offset 0 discusses one side effect of these changes, it should be fixed in HEAD of master and stable now.

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.

Absolutely. Thanks very much.

In T11073#218937, @epriestley wrote:

Do you routinely schedule events in timezones other than UTC or your local time?

Does the language in D17648 look OK?

@epriestley would

The second field (which is the password field) must not be set to !!. This value will prevent login. If it is set to !!, run 'usermod -p NP vcs-user' to block only password logins. If usermod is not available on your system you will need to set the password field value for vcs-user to 'NP' by manually editing /etc/shadow.

be acceptable?

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

In T11073#218834, @epriestley wrote:

I'm just trying to understand whether this is a common problem that all users of Calendar software routinely experience

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

We've run into this a couple of times. When a user updates a revision through the web UI, the repository field (at /differential/revision/update/{REVID}/) doesn't auto-populate with the revision's repository and people sometimes forget to fill it out. This causes the repository to be stripped from the revision as well.

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.

I still had this problem, in a fresh install. Had to run

Then please fork Phabricator to provide this option on your local install. One interested party every few years isn't enough interest for us to add an option, and it's probably 1-2 lines of code for you to provide it for yourself.

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.

Fair enough. I think that if "on the $nth $weekday of the month" and "on $weekday every $x weeks" were to be supported, we would technically be able to schedule all events in Calendar. Do you know if support for this already planned somewhere, or should I create a new feature request?

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.

In T11816#218816, @epriestley wrote:

How do you currently schedule an event in UTC in other software?
I can't figure out how using Google Calendar -- I can't find any option in this dropdown which let me, but maybe I'm just overlooking it? There are approximately 9 million options. I looked for "International", "UTC", etc.

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.