When rebooting the sql server, we get an error on:
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Sep 22 2016
搭建 emulator 的 code review
This should now just work without any changes at HEAD of master. Let us know if you're still seeing issues after updating.
I think this should work better at HEAD of master now -- let us know if you're still seeing issues after updating. Thanks for the report!
Sep 21 2016
Presuming resolved by D16584. Thanks!
Submitted {D16584}
There's a bunch of other Herald stuff we already do for this field so I'm just undoing the change from D14766, at least until someone complains that this field type isn't using the search logic they expect.
Yeah, go ahead and submit a patch. Thanks!
Minimum viable patch sounds good to me, but @epriestley handles all contribs. Not sure what he prefers here. Feel free to patch locally first and verify.
Pretty sure it was copy pasted from something else at the time; I don't believe I would have actually picked a glyph.
So I've figured out the underlying cause. Outlook is sending attachments without a Content-Disposition header. The current version of mimemailparser included with Phabricator completely ignores attachments without that header.
This is still logged as an EXCEPTION. Is DELETE FROM phabricator_repository.edge WHERE type = 39 a reasonable step to take, to prevent administrators unfamiliar with the non-fatal-ness of this from being worried?
To fix:
We don't normally accept bug reports on prototype applications (see Prototype) but this is a one-line fix.
Makes sense, these are old versions of software. I will test with more recent versions of both Windows and Outlook to see if the issue persists.
To fix this:
Or I should say, the amount of time that would be needed to get to Windows 7 issues, would negate the need to support it. We're two developers and any bug is competing with thousands of others.
We have no plans to support Windows 7. Do you have issues with more modern versions of Outlook?
Having the same issue. Seems to only occur on certain panels. Adding the panel in question to a column now creates a duplicate in the opposite column. Removing the panel from one column removes it from both.
With the .eml files, you could change the From: and To: headers and pipe directly into sendmail or similar MTA.
If that doesn't work, I would be happy to provide a VM instance to assist in reproduction.
How can we reproduce this locally? Do you have a specific version of Outlook / OS you are using?
We use a text field for a 'reference number' which refers to tasks imported from bugzilla reference=bz123, or RT with reference=rt456
I think this is the CSS that tries to cut off the titles interacting weirdly with other table CSS.
I believed this was semi-intentional, although the downstream report suggests it worked at one point, so maybe I just made a mistake.
Click "home". to see your installed dashboard. This is the expected UI.
Sep 20 2016
I have that problem again. There is no relation between the file and the Diff. Don't know how that can happen...
Is this reproducible using fields available in the upstream? How can I reproduce this issue against a clean, vanilla, up-to-date copy of Phabricator with no custom code?
We have defined that one. It is like our teams with the company. When new bug is created for example maps team, herald automatically sets the right person/team for the bug.
Where is "Platform--MUST-->" coming from? That isn't a field we provide in the upstream.
phabricator 51f8ec4487be02e290b1182a7cd5b4069fe7d49f (Tue, Sep 20) arcanist 9e82ef979e8148c43b9b8439025d505b1219e213 (Thu, Aug 25) phutil fa6519f4cea1c059bd381c20971cac413cc4760e (Thu, Sep 15)
Ok I have observed this now on this install, however only in the second haunt mode Z+Z:
https://secure.phabricator.com/D15067
@epriestley Did you see the AphrontQueryException: #1364: Field 'messageCount' doesn't have a default value problem too?
Hummm I don't know if it was a transient error or I just happened to magically fix it by force pushing to the repo, but git pulls now work again on my Mac and in CI.
Pushing appears to work (as in the commits appear in Diffusion) but errors are printed:
$ git push # Push received by "web.phacility.net", forwarding to cluster host. # Waiting up to 120 second(s) for a cluster write lock... # Acquired write lock immediately. # Waiting up to 120 second(s) for a cluster read lock on "repo002.phacility.net"... # Acquired read lock immediately. # Device "repo002.phacility.net" is already a cluster leader and does not need to be synchronized. # Ready to receive on cluster host "repo002.phacility.net". Counting objects: 11, done. Delta compression using up to 8 threads. Compressing objects: 100% (11/11), done. Writing objects: 100% (11/11), 1.90 KiB | 0 bytes/s, done. Total 11 (delta 10), reused 0 (delta 0) # Released cluster write lock. PHP Fatal error: Uncaught exception 'FilesystemException' with message 'Requested path '/core/log/hyper' is not writable.' in /core/lib/libphutil/src/filesystem/Filesystem.php:1107 Stack trace: #0 /core/lib/libphutil/src/filesystem/Filesystem.php(650): Filesystem::assertWritable('/core/log/hyper') #1 /core/lib/libphutil/src/filesystem/PhutilDeferredLog.php(183): Filesystem::createDirectory('/core//log/hype...', 493, true) #2 /core/lib/libphutil/src/filesystem/PhutilDeferredLog.php(155): PhutilDeferredLog->write() #3 [internal function]: PhutilDeferredLog->__destruct() #4 {main} thrown in /core/lib/libphutil/src/filesystem/Filesystem.php on line 1107 To ssh://hyper@vault.phacility.com/diffusion/HYPER/hyper.git d77b984..6eb6700 master -> master error: failed to push some refs to 'ssh://hyper@vault.phacility.com/diffusion/HYPER/hyper.git'
Sep 19 2016
Ohhh nice, thank you I missed that
=C124
And you can technically:
Oh, right. That works, but I think isn't documented:
It's an off-case for sure. We have a ton of data identifiers which all end with an equals-sign and a couple letters/numbers, which we abbreviate when referring to the datasets. I was actually trying to render the equals sign as part of the nav sequence and not just C124.
We could conceivably special-case this since setting an empty attribute to a value isn't meaningful, I suppose.
{nav name=C124}Sep 18 2016
Sep 17 2016
Sep 16 2016
Awesome! Thanks for the quick fix @epriestley!
I think the first part of this should be fixed in HEAD now, thanks for the report!
The "multiple packages" issue may have been a symptom of the dominion/archive problem, here's a case I hit while testing that made it look like there was a second issue:
D16564 might fix this but I need to actually test it.
Also, what is the expected behavior if two Owners packages point to the same path?