At our company, we have several interns employed. We want them to learn from each other, as well as from us, so we've tried to set up a workflow that makes the interns review each other. When an intern accepts the reviews, we want the supervisor of the author to have another look and give the final go.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Jul 1 2016
Oh, the group could be a non-blocking reviewer. I think moving a post-check to Herald doesn't solve the underlying problem of reviews being marked as accepted that shouldn't be. Can you go into more detail on what's going on there so we can identify the core problem?
Someone else who's not in the group could've accepted, and the group could be a non-blocking reviewer.
Why are we pushing this check to Herald? Shouldn't the fact that it's accepted mean it's accepted?
First 16 are done and out for review. Next 8 are sent off to the designer, should have them next week. Can explore another set of 8 if needed after that.
We need a platypus. It is objectively the best animal.
I was away for dinner and indeed, it was imported when I got back and everything seems good.!
Looks like it imported before I got to it. Still seeing an issue?
(I also added you to Community, granting you tremendous new power to tidy up around here.)
Ah! That makes sense. Originally we were more strict about which repositories we would update (which would have caught this) but this created some worse/more-confusing effects in the "enroll" direction (see T10940).
No, there's no load balancer. In DarkConsole under Request -> Machine I'm seeing the same IP for both cases. But repo002 is configured to share the db from repo001.
I managed to work around this for now by just doing this manually:
Jun 30 2016
You can also check Request → Machine in DarkConsole to see which host served things, if the Load Balancer / web node thing might be part of the explanation.
(When I toggle between cluster/no-cluster locally with --service / --remove-service, everything appears to be working properly, although I didn't precisely reproduce your setup.)
Just to rule this out, are repo001 and repo002 also web nodes which may receive traffic directly? That is, could this be explained this way?
Humbly suggesting any/all of the following: gun, bomb, skull and cross bones. I find that I type :skull: :gun: on slack a lot (a common side effect of support ops work.)
These will be images in Phabricator, not emoji.
need some food / drinks
added dat boi
ohh, its boaring
I think only frogs are allowed to be memes.
I wish :(
is that from a dank meme i'm not aware of?
- 🐗 For when something is boring.
Thanks for the report! The primary issue should be resolved at HEAD of master, and promote to stable within about 48 hours.
In T11242#183009, @epriestley wrote:In T11242#183007, @chad wrote:{F1706803}
This timely comment saved me a great deal of effort in exporting a high-resolution video of my cat with music and effects or something to get it big enough.
In T11242#183007, @chad wrote:{F1706803}
Thanks for the ridiculously fast triage. Not an urgent issue for us, just wanted to make sure you were aware of it.
{F1706803}
Appears to only occur when a file needs chunked. Small files work fine.
Several behaviors are interacting here. First, here's how MIME types work:
@csilvers, I think you ran into this too although I wasn't around at the time. Likely fixed in HEAD of master.
I'm going to merge this into T6072, which discusses some of these issues in greater detail.
There is now a Edit Related Tasks → Close as Duplicate action next to the existing Edit Related Tasks → Merge Duplicates In action in the related tasks submenu. This change is live on this install:
Happens on test account too
I tried a couple of other devices in the simulator but couldn't get a repro -- can you try this to get a JS trace?
Let me try my spam account.
Nothing unusual. Latest iPhone/iOS
I can't immediately reproduce this in iOS Simulator or on my physical iPhone 4s. What hardware/OS version are you seeing it on?
Please see Contributing Feature Requests and Describing Root Problems to better understand what we consider to be valid feature requests. Specifically we need to know the root problem that occurred that prompted this request to begin with. Right now all we have for information is that too much email was sent out during some operation. There might be other solutions depending what exactly happened and why, to solve this core problem.
The concern here, though well intended, is that it circumvents the audit-ability we build into Phabticator on purpose. We don't know why users have requested to receive notifications,

