Needs More Troubleshooting Info

The documentation just says "the modal is run through a few checks" and that if any of these checks fail you may get a "Sorry, there was an issue adding your email address". That is not enough information to be useful, I am getting this error and it's not a problem with my Xbox Live account as I can log in to it just fine and have tried with multiple accounts always getting the same error.

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 4cfddd1d-f430-c53c-fcdf-26fdd969035f
Version Independent ID: 6af5f347-571a-6a1d-f9df-a26da3f23f79
Content: Authorize Xbox Live accounts in your test environment - Windows UWP applications
Content Source: windows-apps-src/xbox-live/get-started-with-creators/authorize-xbox-live-accounts.md
Product: uwp
GitHub Login: @KevinAsgari
Microsoft Alias: kevinasg

Thank you for taking the time to let us know about this issue. Apologies for the delayed response. Due to the volume of feedback in our content, we are currently prioritizing new issues.
If you believe your feedback still requires an update to the documentation, please let us know either directly in this thread, by filing a new issue, or by filing a Pull Request  with your recommended updates.
Though the Issue will be marked as closed, we will still receive replies and are able to reopen the issue if necessary.
Thanks again for taking the time to contribute.


Implement thread priority into sleeping threads

In a project I was using copas in, I was having issues where copas would not resume a thread correctly which would lead to disconnects with the websocket API I was using, as the connection was timing out because I wasn't able to send a 'heartbeat' when I needed to.
This PR adds a mechanism for setting the priority of a thread as it yields, which in my case alleviated the problem as I could set the priority of the thread which was handling the heartbeats to a fairly high value to ensure it would always be checked in the main loop.

Changes Unknown when pulling 146f252910ba33423a2ab2c42023812156646cae on FiniteReality:master into ** on keplerproject:master**.

Wondering, if connections timeout, then something else is blocking for too long. So maybe you have another underlying issue here?
Or am I not getting it?

@FiniteReality ping any update on this?

Oh wow, I forgot all about this PR. As for things that were blocking, I think the flow was something like this:

Add thread to read data from a socket (I'm using copas in a client-style situation as something like libuv/libev, because I haven't gotten around to learning it yet :stuck_out_tongue:)
Add thread to send data on same socket (The protocol over said socket requires I send a "heartbeat" every 40s or so to ensure my connection stays alive)

Since both "threads" require a constantly running while loop, to allow other code to run I need to yield control to something else, but I couldn't manage to get a socket read to yield until data was available (this is likely my problem) so I ended up hacking something into copas where I could specify "resume this one first if possible" which fixed my problem.
Of course, I haven't touched said code for a long while so I'm not entirely sure if that was the case.

let's close this for now. If thread priority comes up again we can have another look.


Fix building of async-zip where features like "date" or "deflate" are disabled

Signed-off-by: Jiahao XU<EMAIL_ADDRESS>

The CI failed with "no space left on device".
I guess it means testing all combination of features isn't feasible, but I am quite confident in that this PR should pass for any combination of features.

I guess it means testing all combination of features isn't feasible, but I am quite confident in that this PR should pass for any combination of features.

I would probably open another PR later to fix this.
Can you merge this PR please?

Thanks 👍

I would probably open another PR later to fix this.

I've just manually added individual feature tests in the CI so no need to worry about that. Testing every combination was probably a bit too hopeful but was worth a shot.
PS. I recognised your name and I thought you were a previous contributor but then went to your profile and realised it was from Jon Gjengset's last open-source stream. Just found that a tad interesting. 👋


How to copy the specified CID file from the local

I try to use the command and the result is an error.
ipfs-copy --cids=cid.txt --source-api-url=http://localhost:5001 --project-id=xxx --project-secret=xxx
2022/05/20 16:15:17 [INFO] Infura IPFS version is: 0.11.0
2022/05/20 16:15:17 [INFO] Pinning CIDs to https://ipfs.infura.io:5001 with 20 workers and maximum 50 req/s/worker...
2022/05/20 16:16:18 [ERROR] Failed pinning CID 'xxxxxxxxxxxx'. pin/add: pin: failed to get block for xxxxxxxx: context deadline exceeded
2022/05/20 16:16:19 [ERROR] Failed pinning CID 'xxxxxxxxxxxx'. pin/add: pin: failed to get block for xxxxxxxxxx: context deadline exceeded
2022/05/20 16:16:19 [INFO] Successfully pinned 0 CIDs
2022/05/20 16:16:19 [INFO] Failed to pin 2 CIDs
But i can get the file by ipfs command.

d538a5b9376b4e7ab30c9658023a56f0


Defect in "atob" function ?

Hi!
In function atob (fctypes.cpp, line 1044)

suspicious conditional:

s[0] == 'y' || s[0] == 'y'
may be it should be:
s[0] == 'y' || s[0] == 'Y'
?

if ( s[0] == 't' || s[1] == 'T' )
may be it should be:
s[0] == 't' || s[0] == 'T'
These possible defects found by AppChecker.

i don't think it really matters, but this is now fixed.


List of charging states

I got 4 charging states detected:

Disconnected
NoPower
Charging
Complete

but sometimes in a weird state our app comes to an error parsing a charging state.
Are these all, or did I miss one?

Stopped

@fus3d Thanks, that's really helpfull :)

Is there a state for waiting to start, when we schedule the charge? I think i saw it once and maybe it is one o those in the list

Is there a state for waiting to start, when we schedule the charge? I think i saw it once and maybe it is one o those in the list

Jup: it's called: "NoPower". You can handle it like: "Ready to Charge"


[Bug] [flink-sqlserver-cdc will cause duplicate data when checkpoint is enabled]

Search before asking

[X] I searched in the issues and found nothing similar.

Flink version
1.14.1
Flink CDC version
2.4.1
Database and its version
SQL server 2016
Minimal reproduce step
1.Turn on checkpoint

2.Total amount of source database data

3.Total amount of clickhouse target table data

What did you expect to see?
Exactly-once Read
What did you see instead?
Data duplication
Anything else?
No response
Are you willing to submit a PR?

[ ] I'm willing to submit a PR!

While scanning the database table snapshot, a checkpoint cannot be performed because there is no recoverable location. In order not to perform a checkpoint, the SqlServer CDC source will keep the checkpoint waiting for a timeout. Timed-out checkpoints will be identified as failed checkpoints, which by default will trigger a failover of the Flink job. Resulting in repeated consumption of data.


[KAFKA-6485] 'ConsumerGroupCommand' performance optimization for old consumer describe group

https://issues.apache.org/jira/browse/KAFKA-6485
ConsumerGroupCommand describegroup performance optimization.
performance improvement 3 times compare trunk(1.0+). and performance improvement 10 times compare <IP_ADDRESS>
./kafka-consumer-groups.sh --zookeeper <IP_ADDRESS> --group cp-mirror-consumer-group --describe
below is truck version:

below is  performance improvement 3 times:

below is  performance improvement 10 times for <IP_ADDRESS>:

LGTM although I am not a committer :-)

Closing this since the old consumer has been removed from the codebase.


Add json_skip and json_skip_until

I use these functions in my project and I think they should be part of the library.
json_skip_until is useful when parsing JSON via json_next in a loop, and there's a need to skip JSON_OBJECT or JSON_ARRAY completely with all their children.
In that case one should call:
json_skip_until(json, JSON_ARRAY_END);

or
json_skip_until(json, JSON_OBJECT_END);

json_skip is used inside json_skip_until, but also can be useful as a standalone function.
For JSON_OBJECT and JSON_ARRAY it just skips them with all their children, for other types it is the same as json_next.

Both these functions return immediately on JSON_DONE and JSON_ERROR.

I like this as a convenience function, but I believe it can be done
without mutual recursion — e.g. without risking a stack overflow. When
skipping an array, keep a running counter of how many arrays are opened,
ignoring objects. When skipping an object, count objects instead.
The general parsing case has to keep track of both in order to detect
errors, requiring a stack. However, the parser is guaranteed (outside of
JSON_ERROR) to return correctly-matching array/object pairs, so this
helper function can do it with a simple counter.
Am I missing anything?

 It's possible to implement these functions without recursion.
I've updated the PR.
Note that I don't check for cnt_obj and cnt_arr size_t overflow, since there's a check for json stack overflow inside json_next.

Looks great, thanks! I like this version a lot better. Merged.


R containers don't want to shut down

Containers running the R remotebmi seem to not want to shut down gracefully, as the R terminal seems to ignore interrupts.

Changing "R" to "Rscript" fixed this.


Allow the parser to continue past errors

From what I can tell, the parser has always stopped after hitting an error, halting any tooling until the error is solved. Prior to 3.1, this was fine, since dynamic typing made parse errors pretty uncommon.
Now with typing in 3.1, parse errors are much more common, and can greatly interfere with a workflow. For example, say I start coding something that will not fully work until I code something else. So i code it partially, then jump to the thing I need to code in order to complete it. But nope, my tooling won't work because the partially written code is throwing errors about missing variables and whatnot. So i have to make sure that no parse error is around so that I can code more comfortably elsewhere.
There is also the issue that it prevents further errors from being able to be detected until the current error is fixed. As said, this used to not be as big of a deal before, but with typing being introduced in 3.1 this calls for much better tooling.

In 4.0, GDScript was rewritten to allow reporting multiple errors at the same time. The script editor was also refactored to handle
this, closing.


unified UI to backend comms

UI calls to backend should include UI token ("app id") and a unique identifier (acting like a current "app secret") that isn't the session id. As per discussion these should be in http headers. "Post" or "put" data is, as usual, sent via JSON.
see http://stackoverflow.com/questions/7686827/how-can-i-add-a-custom-http-header-to-ajax-request-with-js-or-jquery for appending custom headers
(also see #596)

dupe of #596

not a dupe, merely its frontend counterpart