I think this use case is a reasonable one.

Yeah -- the workflow from the Maniphest side dumps all the values into inputs in the body and does a POST, I believe.

@swisspol hit a variant of this with 1,172 tasks bumping up against an Apache URL limit in the Phacility cluster when editing from a workboard column.

I used the current version, but there should be no meaningful changes to this behavior between your version and HEAD.

I can't reproduce this. Here's what I did:

How did you generate this diff?

I moved everything except one test instance off in T12817, and we appear to be ready for this host to die.

I believe this should now be resolved in HEAD of master. Let us know if it doesn't work for you or if you're still seeing issues after upgrading. Thanks for the report!

No one has complained that all their data is gone so I'm going to assume the best here.

This is not a configuration problem, and you can't fix it by changing configuration. D18119 should fix it.

Presuming resolved by T12757 (May 25).

Version?

Not exactly related, but these cancel buttons used to be grey and are now blue:

Some other general thoughts:

Sorry, I guess I'm being unclear: I don't believe that (1) is a reasonable starting point.

I think maybe we're talking about a couple different things? These are both relatively easy:

have a flagged filter automatically everywhere

Maybe also, in general, we could define an "explore by tags" view, that works something like this:

Constructively, some adjacent changes which are maybe worth considering instead:

The requests I've seen seem like users want this done automatically/by default, not that they want better tools to do it themselves.

On a purely personal/aesthetic level, the box-drawing character block is total garbage and master ASCII artisans would never use it in serious work. A true connoisseur of the craft should accept nothing more than single-byte ASCII range in their collection.

See some related discussion in T12822. In particular:

me too but not everyone is on our level

• T2495: Improve whitespace expansion of tab literals is somewhat adjacent here.
• T11632: Display invisible characters on erroneous user input is a little related: if we generate canonical lists of "invisible" characters in UTF8, they should probably be shared by all three of: the code that detects when input in forms is invalid because of invisibles; the future UTF8-aware invisible mode; and the UTF8 text linting mode described in T11150.

Per above, these are already detected by the Text linter:

See also T4124 for another Solaris issue.

The move completed without errors.

Instances are moving now.

Deploying, then picking this up again.

I suspect some of those features have no actual use case outside very marginal nonsense like T12799, but they're "things computers should be able to do".

I want to get clear of T12798 first, but there are some other features I'd like to add to our search anyway, including:

I'm going to call this "resolved" since I migrated instances in T12817 successfully. There's followup work, but T12798 is probably a better point of consolidation for future work now than this task is.

The disabled/suspended instances finished up with no apparent issues, so I expect to move the live instances tomorrow.

A verrrry minor thing is that because we always transfer a repository backup (even if it's empty), a migration always generates a repository directory on the far end. We could maaaybe have restore remove the directory if it's empty after the restore finishes to tidy this up just a touch.

Maybe just include name, value, closed and special?

I'm moving all the disabled/suspended instances now.

With those changes, bin/instances move completed successfully.

As a sort of aside, --global --instance X is really slow right now (about 10s), and will only get slower in the future: it loads every instance page by page over Conduit, then does the remaining filtering by name locally. But it gets the right result, so this is reasonable enough for the moment. I may try to tune this before moving a lot of instances.

I hit two more minor issues:

bin/host restore failed with this error:

I read and wrote the repository and verified that the data really ended up on db012 and repo025.

I launched yellow-underneathie.phacility.com with forced services dbx012 and repox025. My goal here is to check for any code I missed which makes the assumption that dbX = repoX. I believe we don't have any of this code, but if we do, this instance should point out whatever problems we have that still need to be cleaned up.

• Swap stuff finished up.
• I merged master to stable for services/ to pick up bin/services sync --src ... --dst ....
• I merged master to stable for instances/ to pick up bin/instances move ... and related changes.
• core/ just runs master so nothing needed to merge.
• I upgraded repo025, then repo012, then admin001. None of these seemed to hit any issues.

While that's running, I closed dbx012 and repox012 to new allocations. The shard status panel correctly reflects repox025 with no paired DB service and the 012 shard as closed:

• I launched repo025.phacility.net, like other hosts in the tier.
• I added repo025.phacility.net to DNS in Route 53 (172.30.0.115).
• I added a device record (repo025.phacility.net) to Almanac on admin.phacility.com.
• I added a service record (repox025.phacility.net) to Almanac on admin.phacility.com, and bound it to the device.
• I added a device record for the backup volume, rback025.phacility.net.

I think the next steps are:

I cleaned up all that stuff and it doesn't look like I broke the world.

I think this means we don't need to migrate every host: the problem with swapping block001 over to be NAT'd was probably that the NAT gateway itself couldn't reach the public internet. When we changed the 0.0.0.0/0 rule to nat-..., that blocked the NAT gateway itself from getting out.

• I launched a new NAT gateway into the public subnet (block001); nat-0d470fc54d846a993.
• I reconfigured the private subnet route table to point at the new gateway instead of the old one.
• I can now reach the public internet from the host on the private subnet:

I think the problem is that the NAT gateway is currently in the private001 subnet, but needs to be in the public subnet (the NAT gateway itself must have a route to the public internet).

• I stopped the host, and got kicked off as expected.
• I started the host.
• Problem: This failed to magically fix anything, and I still can't connect to the public internet.

• I built a new route table, following the main route table.
• I replaced the target for the 0.0.0.0/0 rule with nat-... instead of igw-....
• Under "Endpoints", I added the new route table to the S3 endpoint so the private subnet can access S3.
  • (This wasn't immediately reflected in the "Routes" UI, but it's not important for now so I'm going to assume it's a propagation issue until I need it.)
  • (It showed up about a minute later.)
• I changed private001.phacility.net to use the new route table, with nat-... instead of igw-....
• I can still connect to the test host from the bastion.
• Problem: I still can't connect to the public internet from the test host.

• We launched a new private subnet (private001.phacility.net) yesterday.
• I launched a new instance (nat-test001.phacility.net) into this subnet, with no public IP.
• I can connect to the instance from the bastion host (bastion005), which is good.
• Problem: I can not connect to the public internet from the test host.

The behavior of arc land is complex. You can look at the source for the details, or run arc land --trace to see which commands it executes.

Per @chad's link, PholioMockEditor->buildMailBody() does some improper stuff where it explicitly sets rendering targets and adds raw sections to the mail body.

Prior to October 2015, this flag only had an effect under git. This is why it says "Supports: git".

Arc supports auto-deleting the remote branch as well as the local one

The version of arcanist used is the one packaged in debian.

See T12814.

Maybe this was the workflow?

To set expectations, this is an exceedingly low priority for the upstream and these tasks basically only move forward when an existing customer requests integrations.

(T12812 wants custom headers, but the only use case appears to be better covered by T12813.)