Yay! Thank you.

As was mentioned, there was code already for detecting a hidden hash/anchor and loading older transactions/comments to allow it to be reached. Turned out it was a cinch to hook it up, which I've done in D16256.

We might have had some kind of dialog action from lightboxes in the past (or planned to have one -- like image inline comments?), but didn't have a lightbox action from dialogs until inline previews.

This was fixed by D16238 (Tuesday, July 5). It's available at HEAD of master and will promote to stable and be available in the Phacility cluster in a little more than 24 hours.

A possible fix to this is to handle ` on keydown instead of keypress (as we do for some other other keystrokes) but since we can't reproduce it we can't test that.

Your database may not have proper column encodings configured. Run this command to verify them:

D16253 should fix this; a quasi-workaround in the meantime is to set "Short Names" on repositories.

Thanks for the quick replies and actions, this is greatly appreciated.

I can't think of any reason it would ask that unless something changed locally. If you have no local changes to phabricator/, just reset to HEAD.

@chad I don't know, I installed phabricator under the direction of doc and then resolved some setup Issues.

(Or likewise with the task ID.)

Is the commit ID exactly the same each time, or does it change?

Correction, not hanging, but continuously re-scheduling that task in the queue (which is slowing up the queue significantly)

Follow up question, this task has failed 38022 times.. is there some way I can punt it from our queue?

No problem, thanks for the followup!

@epriestley - this is caused by a downstream patch which intentionally excludes sprints from the displayed groups.

Presuming this is resolved now, let us know if you're still seeing issues.

I intend to remove them from feed, but it might have just been on a diff somewhere and not made it to a task.

I can't find the task. I'm like 98% sure @epriestley made one because someone kept spamming it on us.

test notifications

We'll eventually not publish stories at all ...

We'll eventually not publish stories at all (i think there is another task, just can't find it). For now though this is working as intended.

I've looked at the database, specifically the worker_activetask table. The bad transactions appear to be linked to profile panel objects (objectPHID like PHID-PANL-...).

Why do you have local changes in your phabricator folder?

Sorry to trouble you @epriestley , I have the same question(T11273) . After your committing rP5ffdb732735c, I tried to update my phabricator under the direction of doc(https://secure.phabricator.com/book/phabricator/article/upgrading/). While I executed git pull，the terminal shows

It was merged into master today.

Looks like this should be available in 7.1 btw: https://wiki.php.net/rfc/async_signals#proposed_voting_choices.

Thanks for the report! This should be resolved in HEAD of master.

We are also able to reproduce this on our installation.
Currently we are using Version 05699388804fc6ae1df5a17559917d218c4ec26d of phabricator.

Your answer is right here:

Thanks.

https://secure.phabricator.com/book/phabricator/article/diffusion_uris/

A possible alternate approach would be to attachRepository() as a side-effect of validating the transaction instead of while applying the transaction, but then if something throws between the "validate" and "apply" steps we could end up with a URI in a weird state. That probably never actually matters, but feels a little more awkward to me than ordering the transactions.

ok, that makes sense.

It's impossible to create a URI without a repository transaction (it doesn't make sense, since URI objects can't just exist), and we already give you an appropriate error when you try:

That kinda feels like a band-aid... Shouldn't we be able to not-crash for any input? Like if a user will only provide a uri transaction?

My initial thought is that we should just reorder these transactions. We should use a stable sort, but that's relatively easy now that we have msortv(). There are probably a handful of other transactions with similar properties in other object types.

if it helps anyone, the workaround "fix" is to place the following code in the file "src/applications/conduit/parametertype/ConduitBoolParameterType.php "

Thanks for the report! I believe this should now be resolved in HEAD of master.

T9854 is also vaguely related, but fairly separate.

I'm going to merge this into T11269, which I believe describes the same problem.

Thanks for the report! I think this should be fixed at HEAD of master. Let us know if you're still seeing issues after updating.

I'm having the same issue since I updated from week 21 to week 27, it happens on empty repositories.

The support cost for the current behavior is very small. The behavior of the system is obvious. Users can file precise tasks like this one which clearly describe the problem (or find this task):

This behavior is intentional; it allows users to use a credential to configure other applications without actually having access to the plaintext.

Thanks for the quick response. I'll let you know as soon as the change gets merged into stable.

Of course! Thanks for poking around!

I received this e-mail recently: