Mobile agent not receiving credentials after reconnecting to the mediator

Hi there,
we are using aries-framework-javascript in 2 instances:

as a mobile agent, using react-native
as a mediator, using node in Docker
Credentials themselves are issued using aca-py.
Everything works fine when the mobile app is active.

As you're probably aware of, iOS inhibits network connections when an app goes to the background.
Our understanding is that the mediator would store the messages received when the mobile app is unreachable, and would send them once the mobile app reconnects.
We're seeing a consistent scenario where credentials transmitted to the mediator through messages of type "did:sov:BzCbsNYhMrjHiqZDTUASHg;spec/routing/1.0/forward" are never delivered to the mobile agent.
When the mobile agent reconnects, it sends a "https://didcomm.org/messagepickup/2.0/status-request" message to the mediator, which responds with a "https://didcomm.org/messagepickup/2.0/status" where where message_count = 0...
Since ensuring consistent async delivery of messages is the primary purpose of the mediator, it seems we are missing something, but what ?
We're using 0.4.0 on mobile side and 0.4.1 on mediator side (running the provided Docker).
Worth noting, our mediator is not connected to a persistent database.
Help would be appreciated.
Thanks

If your mediator is not connected to a persistent database, you'd lose all connections / messages when it restarts. But that doesn't seem to be the problem here.
Have you looked at the logs whether the messages are being queued or sent directly to the device?
In theory when using pickup v2, the messages sent by the mediator should be acked by the client, and then they'll be removed: https://github.com/hyperledger/aries-rfcs/tree/main/features/0685-pickup-v2#messages-received
@genaris is it correct this is how this is implemented?
If you can provide logs of both sides, and analyze them we can probably figure out a bit more on what the underlying issue is here.

Hi, thanks for your kind proposal to help.
Attached are 2 log files.
In the mobile log, you'll notice that the invitation (around 12:26:02) goes well.
At 12:26:18, the mobile app goes to the background, as part of that we close the 2 outbound transports.
At 12:28:18, the mobile app becomes active again, as part of that we reopen the 2 outbound transports.
In the mediator log, you'll notice that in the meantime, the mediator receives 3 'forward' messages, at 2023-09-06T10:26:07.541Z, 2023-09-06T10:26:22.418Z and 2023-09-06T10:26:26.049Z. The logs don't say whether these were forwarded, stored or queued, but since I'm not seeing any "Send outbound message" for these in the mediator log, and not seeing any corresponding "Received message with type" in the mobile.log, I'm assuming they are 'stored' somewhere...
I hope this helps.
Eric
mobile.csv
mediator.csv

@TimoGlastra  yes, it works like that but in this case it seems to me that the problem is related to the way WebSockets are being managed.
Looking at the logs it seems to me that the, at the moment of processing the first forward message (2023-09-06T10:26:07.541Z) mediator still sees the WebSocket as opened, so it sends it through the existing WebSocketTransportSession. A few seconds later (2023-09-06T10:26:09.996Z) it receives a WebSocket closed event.
So when the mediator sends the Forward message to that 'phantom' WebSocket, it thinks everything is fine and considers it has delivered the message (no need to queue it anywhere). However, the app won't receive any message and will not have any way of retrieving it, making the message effectively lost (which is certainly terrible).
Why it does think a WebSocket is opened when it is not? It can be caused to a number of reasons that I've identified based on the experience I had with mobile apps and AFJ in both sides:

Client shuts down unexpectedly, meaning that it won't close the socket gracefully (typical case when mobile phone has poor connectivity): if no specific heartbeat mechanism is done at the app level, it depends on the OS/low-level layers to let the app know if the socket is effectively closed
Client shuts down gracefully, but a message has been received during the shut down process (this could be what happened here, given the short time frame between the Forward and the WebSocket close): WebSocket was opened, low level layer library has received it and probably notified the app but it was already deciding to shutdown so it ignored it
Connection is established but the message could not be delivered:

React Native event emitter is not sending the message event (this happens to me quite often when refreshing the app or switching background/foreground, mostly in development mode). I got better results by using the onmessage callback instead of the event listener as done in the default WsOutboundTransporter
In Node.JS OS doesn't emit any error when ws.send() failed to deliver the message

In practice, most of these issues can be solved or reduced by implementing at mediator level a heartbeat mechanism where it does a ws.ping every n seconds (we found 3 to be a good number). This implies some updates to WsInboundTransport.
But I think that at some point it will be needed in Live mode to stop using regular "Forward" messages (which don't require any acknowledgement) and use Delivery instead, which as @TimoGlastra mentioned do require confirmation. See the discussion here: https://github.com/hyperledger/aries-rfcs/issues/760
I'm testing a mechanism like that, which for the moment is a bit tricky to 'standardize' but I think can be useful to add to AFJ in the next major version (as it will need to break the very dated MessageRepository API).

Hi,
thanks for that.
I did notice that the first message occurred during a gray area. But what about the 2 other ones ?
Re a switch from "Forward" messages (which don't require any acknowledgement) to Delivery, is that a change within the mediator itself ? or does it require a change in the way other components (such as mobile or aca-py) talk to the mediator ?
I noticed that "forward" messages have no identified sender, so I'm assuming the sender if the mediator itself, is that a valid assumption ?

This can only result from either of:

messages beings sent despite the WS socket being closed, even long after the WS is closed
messages being stored (without logs ?) but not retrieved by status-request

I think it is the first one, because when mediator queues a message it does print a Queue packed message for connection ... legend in the debug log. And when it forwards a message for a connected session succesfully, it currently does it so silently (it would be nice to be more verbose on this).
So IMHO the mediator agent considers there is an opened WebSocket for the mobile agent and that's why it forwards the messages. It does not receive any error from lower level layers so it does not throw any error.
Based on the mediator log from the time you mentioned the mobile agent transports were stopped and the app went background, I see (leaving only relevant parts):

2023-09-07T11:53:01.844Z	Socket closed.
2023-09-07T11:53:02.713Z	Socket connected.
2023-09-07T11:53:02.936Z	Received message with type 'https://didcomm.org/messagepickup/2.0/status-request',
2023-09-07T11:53:02.964Z	Storing session for inbound message '09ec1f67-50c1-4765-8c42-c9efc0c0b24f'
2023-09-07T11:53:02.965Z	Send outbound message {  '@type': 'https://didcomm.org/messagepickup/2.0/status',   message_count: 0 }
2023-09-07T11:53:02.968Z	Pack outbound message https://didcomm.org/messagepickup/2.0/status
2023-09-07T11:53:07.289Z	Received message with type 'did:sov:BzCbsNYhMrjHiqZDTUASHg;spec/routing/1.0/forward'
2023-09-07T11:53:08.277Z	Received message with type 'did:sov:BzCbsNYhMrjHiqZDTUASHg;spec/routing/1.0/forward',
2023-09-07T11:53:08.500Z	Received message with type 'did:sov:BzCbsNYhMrjHiqZDTUASHg;spec/routing/1.0/forward',
2023-09-07T11:53:14.904Z	Received message with type 'did:sov:BzCbsNYhMrjHiqZDTUASHg;spec/routing/1.0/forward',
2023-09-07T11:53:20.092Z	Received message with type 'did:sov:BzCbsNYhMrjHiqZDTUASHg;spec/routing/1.0/forward',
2023-09-07T11:53:20.454Z	Received message with type 'did:sov:BzCbsNYhMrjHiqZDTUASHg;spec/routing/1.0/forward',
2023-09-07T11:53:34.417Z	Socket closed.
2023-09-07T11:53:34.419Z	Socket closed.
2023-09-07T11:56:34.616Z	Socket connected.

And also the mobile log at that particular time (ordered backwards):
"2023-09-07T11:53:02.875Z",,"""com.getpocketdev""","Successfully connected to WebSocket wss://dev.getpocket.io/aries_js"
"2023-09-07T11:53:02.745Z",,"""com.getpocketdev""","Stopping HTTP outbound transport"
"2023-09-07T11:53:02.744Z",,"""com.getpocketdev""","Stopping WS outbound transport"
"2023-09-07T11:53:02.085Z",,"""com.getpocketdev""","Connecting to WebSocket wss://dev.getpocket.io/aries_js"
"2023-09-07T11:53:02.084Z",,"""com.getpocketdev""","Sending outbound message to endpoint 'wss://dev.getpocket.io/aries_js' over WebSocket transport."
"2023-09-07T11:53:02.079Z",,"""com.getpocketdev""","Pack outbound message https://didcomm.org/messagepickup/2.0/status-request"
"2023-09-07T11:53:02.079Z",,"""com.getpocketdev""","Sending outbound message to service:"
"2023-09-07T11:53:02.073Z",,"""com.getpocketdev""","resolving didUrl did:peer:1zQmWSZezhx42Bc6FT5Nzo7DgZAdy7M4Zyzv4D66PUzubW3x"
"2023-09-07T11:53:02.072Z",,"""com.getpocketdev""","Retrieved 2 services for message to connection '13f38ad1-6ae3-4976-b5cd-2a5dba4f222f'(Aries Framework JavaScript Mediator)'"
"2023-09-07T11:53:02.066Z",,"""com.getpocketdev""","resolving didUrl did:peer:1zQmYPrUCb1HJ9vup3AY2xKFvF2qWsZbZpTDVQPLnpohKfgH"
"2023-09-07T11:53:02.066Z",,"""com.getpocketdev""","Resolving services for connection theirDid did:peer:1zQmYPrUCb1HJ9vup3AY2xKFvF2qWsZbZpTDVQPLnpohKfgH."
"2023-09-07T11:53:02.066Z",,"""com.getpocketdev""","Retrieving services for connection '13f38ad1-6ae3-4976-b5cd-2a5dba4f222f' (Aries Framework JavaScript Mediator)"
"2023-09-07T11:53:02.066Z",,"""com.getpocketdev""","Send outbound message"
"2023-09-07T11:53:02.053Z",,"""com.getpocketdev""","Websocket connection to mediator with connectionId '13f38ad1-6ae3-4976-b5cd-2a5dba4f222f' is closed, attempting to reconnect..."
"2023-09-07T11:53:01.951Z",,"""com.getpocketdev""","WebSocket closing to wss://dev.getpocket.io/aries_js"
"2023-09-07T11:53:01.786Z",,"""com.getpocketdev""","Stopping HTTP outbound transport"
"2023-09-07T11:53:01.786Z",,"""com.getpocketdev""","Stopping WS outbound transport"
It seems to me that the mobile agent tried to re-connect to the mediator as soon as you stopped the transports for the first time (11:53:01.786Z), and it didn't actually closed the socket when stopped the transports the second time and it went background (you can see a WebSocket closing to... legend the first time, but the last log we have from the mobile is Successfully connected to WebSocket).
This makes me think that the resulting WebSocket was not closed gracefully, so the mediator considered it to be opened until 11:53:34 (around 30 seconds after), when it received two WebSocket closed events. We don't have further information, but maybe those correspond to both the mobile agent and the agent you are using to send messages to it.
It might be also possible for the WebSocket to be actually opened and the connection between mobile device and iOS to be responsive. To make sure about that, as I suggested previously, I think we can use a heartbeat mechanism in the WsInboundTransporter to send pings periodically. That will give us more details about what's going on and eventually fix the issue as well. Here you can see a custom implementation that you can use in your mediator as inbound transporter:
WsInboundTransport.txt

Also, wouldn't it be more effective to call socket.terminate() which doesn't suffer from the undeterministic behaviour of socket.close() ?

I don't see terminate() available in react-native. Is it? But I'm curious about the statement that close is undeterministic. AFAIK the main difference with terminate is that the latter will drop the connection immediately without executing the closing handshake. Would that be more reliable in this case? At first sight, it seems to me that it would be worst.

I see ping messages flowing so it looks like there is already some heartbeating going on

Not sure if you are referring to the same thing as I do: the ping messages I'm talking about are the ones at the WebSocket protocol level. In your logs I can only see 'Trust Ping' messages exchanged, which is an special type of DIDComm message. In this case it is used as an acknowledge for Status and also for connection establishment, but not periodically sent under the hood to check the link.

Thanks for this.
By undeterministic I mean that we don't know, at call time, whether or not it succeeded. And clearly the mediator isn't told about it.
Maybe because it is marked async, so the underlying close() doesn't happen in a meaningful time.
But maybe the transport should reject outgoing messages when it's closing, instead of reopening the socket.
On the mediator side, I'm not convinced that a heartbeat will prevent message loss. Imho it would just improve the odds that the socket is live. How about awaiting a technical ACK sent over the http channel in response to the DIDComm message ? It doesn't affect the protocol itself but would provide transport level guarantees of delivery. What do you think ?

I also notice on mediator side, that in WsInboundTransport, there is no error handler installed when the socket is connected  (line 34), and that send() doesn't check for errors either (line 96). Is this intended ? Would it make sense to check for errors on send() and raise the corresponding error if it failed ? (happy to try that out myself)

Noted, I'll try that out and keep you posted

Just reading this last note — not the whole stream.  Indicio has implemented SocketDock that I think addresses the questions raised here. Perhaps it can help. Quick overview — SocketDock is a component to handle web sockets in front of a scalable component (say, Aries) that can then just use HTTPS to send messages reliably.

Thank you @ericvergnaud , your findings are certainly very, very valuable. It is true that the solution of ping-pongs work well in certain scenarios (like agents going offline) but not the one you mention about apps going background and then foreground in iOS.
Regarding this, I have a question: even if you stop the WsOutboundTransport before the app goes background iOS keeps the WebSocket opened? So there is no way to actually forcing it to close in this platform?

By nature web sockets are unreliable so I believe that using fire-and-forget protocols over websocket is likely to frequently fail. I am impatient to see how #76 evolves, and when it becomes available in aries-framework-javascript ?

100% agree (especially the one about being impatient 😝). I'm working on it and hopefully will be integrated in the next major release (0.5.0).

@swcurran thanks for that. Looking into it

It didn't work well because the underlying socket wasn't getting closed deterministically (remember me mentioning that earlier ?). It could be because transport.close is async, so its execution is queued in the event loop, or it could be that a new socket was opened by another thread (this isn't single JS thread V8!).

I don't think the async is a problem, as long as you are calling it like await transport.stop(). In my opinion, based on the mobile logs you shared, when you stop the WsOutboundTransporter, the MediationRecipientModule detects it has disconnected from the mediator so it attempts to re-connect with it, opening a new socket and exchange a some messages (like status request and trust ping) just before the app goes background.
I know this is does not make sense, as when we stop a transporter one would understand that no new sessions may be opened, but for the moment it is working like that.
A way to get around this issue can be to call agent.mediationRecipient.stopMessagePickup() before stopping the outbound transporters. Then you'll need to call agent.mediationRecipient.initiateMessagePickup() when the app goes back to foreground.

@swcurran at first glance in seems the product is meant to fill a gap for backends without WebSocket support, but they don't say anything about WebSocket transport reliability...
Again I suspect the only viable solution is to rely on acknowledgments at the aries protocol level.

@genaris thanks for this, we'll try it out

Again I suspect the only viable solution is to rely on acknowledgments at the aries protocol level.

Yes, I think this is how we should solve this. This also makes it agnostic of the transport being used, and means it won't be impacted by any transport level issues. We should probably:

in the receiver side keep a lot of all messages that have been received and processed. If a message is received that was already processed we discard it and don't process it again
On the server side we need to be able to mark messages as 'sent', but don't remove them until they have been acknowledged. If the message hasn't been acknowledged in x time, or until a new session is opened the next time or until a new status request is received, it should be re-sent to the client.

Both sides make sure in this case that messages are not lost, but also not processed multiple times.

@TimoGlastra indeed the receiver needs to guarantee idempotence i.e. the same message received twice should only be processed once

@genaris whilst trying out your suggestion we've also tried ping-pong-ing the receiver before sending the message. For those interested, here is our code change in WsInboundTransport.ts:
  public async send(agentContext: AgentContext, encryptedMessage: EncryptedMessage): Promise<void> {
    if (this.socket.readyState !== WebSocket.OPEN) {
      throw new AriesFrameworkError(`${this.type} transport session has been closed.`)
    }
    // websockets get closed by infrastructure after a given timeout (typically 60s)
    // this is expected and desirable, otherwise the number of opened web sockets could become unmanageable
    // but when a mobile app becomes inactive, it stops processing websocket messages until it becomes active again
    // as a result, messages sent whilst the app is inactive are irremediably lost when the websocket is closed
    // in order to minimize the risk of message loss, we do a ping/pong and only send the message when the pong is received
    let success = false;
    let timeoutId: any | null = null;
    const delay = (ms: number, val: any) => new Promise( (resolve) => { timeoutId = setTimeout( resolve, ms ) })
    this.socket.once("pong", () => {
      this.socket.send(JSON.stringify(encryptedMessage), (error? : Error | undefined) => {
        if (error != undefined) {
          const message = `${this.type} send message failed.`
          this.logger.debug(message + " Error: " + error)
          throw new AriesFrameworkError(message, { cause: error })
        } else {
          this.logger.debug(`${this.type} sent message successfully.`)
          success = true;
          clearTimeout(timeoutId)
        }
      })
    })
    this.socket.ping("ping")
    await delay(10000, () => success = false)
    if(!success) {
        const message = `${this.type} send message timed out.`
        this.logger.debug(message)
        throw new AriesFrameworkError(message)
    }
  }

To avoid confusion, I HATE this code :-)
But it works i.e. when the mobile app is in the background, the pong is never received, so the error is bubbled up and the message gets queued (corresponding logs in PR #1573 ), and they are sent later when the app becomes active again.
So it's a temporary workaround that might be useful to readers, but certainly NOT a fix !!!

Any reliable solution we got on this?
For Workaround, we did stored connection request message in connection itself, same for credential offer message as retry mechanism.
Whenever new invitation is scanned, we are checking if there is some connection id for that invitation and connection is not in response_received, we are retrieving that connection request message and sending again to issuer.
Same thing is handled on issuer side if connection is not in acked state, resend response back.
There were some changes done in connection request, connection trust ping, credential offer accept flows for this.
Can I raise PR for these changes?


Support for Wagtail 3 and Django 4

pip downgrades the Wagtail and Django versions when adding wagtail-oauth2 to the environment at the moment. Would it be possible to:

remove the upper versions constraints in pyproject.toml
add support to the newer frameworks versions if needed?

Thank you for sharing library's code to public.

Hello @m-aciek,
Thanks for the report!
Wagtail 3 is still in release candidate but as we plan to upgrade our projects to Wagtail 3 when it will be available, I created a ticket internally to fix the problem.

As a reference I'm sharing a link to a discussion against the dependencies versions capping: https://iscinumpy.dev/post/bound-version-constraints/.

Wagtail 3 is now released - can this get updated?

Hello, I've just made the needed changes to make the plugin working on Wagtail 3.0 and Django 4.0. A 1.0.0 release has been pushed on PyPi. :)


Polymer.Base.splice and dom-repeat

See wf-list line 46 for the non-working code and work around for this possible bug
http://plnkr.co/edit/JbKfgS74X7JvtZeA4wCv?p=preview

Should be fixed in: https://github.com/Polymer/polymer/pull/1739
Verified in your use case here:
http://plnkr.co/edit/oz9rIB7sos0VToAjqr3A?p=preview


Improve binary API documentation

This PR focuses primarily on improving API documentation.
It also does some modifications to code that deals with intricate logic to make
it easier to read for both users of the API and maintainers.
As always, I suggest having a look at the commit messages to get some hints on
the concrete tasks carried out in every commit. My plan is to open a new PR
soon targeting structural changes to the API, to make it usable from both Java
and Scala.
In short, this PR:

Documents better the compiler interface, the compile core project and the
zinc project.
Starts to define the interface of IncrementalCompiler.
Removes unused imports, and makes hard-to-grasp code more readable.

Review by @dwijnand, @romanowski, @eed3si9n.

+2,421 −798

Thankfully lots of it is just text, but, still, that's a big PR :)

This is ready for review.


Updated today, eqMac no longer works

Now at:
App 1.7.1
Driver 2.3.0
UI: v4.4.1 (Remote)
macOS Catalina 10.15.7
Worked up until the update, the UI still works, but not actually changing any EQ; that's all I have to report. That and thank you for a cool audio utility!

exactly same for me

Can you please try this release:
https://github.com/bitgapp/eqMac/releases/download/v1.7.2/eqMac.dmg

already answered in https://github.com/bitgapp/eqMac/issues/769
you can just downgrade to the old version: https://github.com/bitgapp/eqMac/releases

Confirming this problem on macOS Mojave 10.14.6, and confirming v1.7.2 resolves the issue.

Looks like this issue is solved. If this is not the case, please open another issue along with the details of it. Thanks!


The bot don't walk

The log show me this.
[21:02:05] Spinning ...
[21:02:05] Loot:
[21:02:05] 50 xp
[21:02:05] - 2x Pokeball (Total: 129)
[21:02:05] - 1x Greatball (Total: 4)
[21:02:05] PokeStop on cooldown. Time left: 4 minutes, 44 seconds
[21:02:07] Walking from (40.41615589414066, -3.67896573069202) to [40.41615589414066, -3.67896573069202] 0.00km
[21:02:09] Walking from (40.41615589414066, -3.67896573069202) to [40.41615589414066, -3.67896573069202] 0.00km
[21:02:11] Walking from (40.41615589414066, -3.67896573069202) to [40.41615589414066, -3.67896573069202] 0.00km
[21:02:12] Walking from (40.41615589414066, -3.67896573069202) to [40.41615589414066, -3.67896573069202] 0.00km
[21:02:14] Walking from (40.41615589414066, -3.67896573069202) to [40.41615589414066, -3.67896573069202] 0.00km
[21:02:16] Walking from (40.41615589414066, -3.67896573069202) to [40.41615589414066, -3.67896573069202] 0.00km
[21:02:17] Walking from (40.41615589414066, -3.67896573069202) to [40.41615589414066, -3.67896573069202] 0.00km
[21:02:19] Walking from (40.41615589414066, -3.67896573069202) to [40.41615589414066, -3.67896573069202] 0.00km
[21:02:21] Walking from (40.41615589414066, -3.67896573069202) to [40.41615589414066, -3.67896573069202] 0.00km
[21:02:23] Walking from (40.41615589414066, -3.67896573069202) to [40.41615589414066, -3.67896573069202] 0.00km
[21:02:24] Walking from (40.41615589414066, -3.67896573069202) to [40.41615589414066, -3.67896573069202] 0.00km
[21:02:26] Walking from (40.41615589414066, -3.67896573069202) to [40.41615589414066, -3.67896573069202] 0.00km
[21:02:28] Walking from (40.41615589414066, -3.67896573069202) to [40.41615589414066, -3.67896573069202] 0.00km
[21:02:29] Walking from (40.41615589414066, -3.67896573069202) to [40.41615589414066, -3.67896573069202] 0.00km
[21:02:31] Walking from (40.41615589414066, -3.67896573069202) to [40.41615589414066, -3.67896573069202] 0.00km
[21:02:32] Walking from (40.41615589414066, -3.67896573069202) to [40.41615589414066, -3.67896573069202] 0.00km
[21:02:34] Walking from (40.41615589414066, -3.67896573069202) to [40.41615589414066, -3.67896573069202] 0.00km
[21:02:36] Walking from (40.41615589414066, -3.67896573069202) to [40.41615589414066, -3.67896573069202] 0.00km
[21:02:37] Walking from (40.41615589414066, -3.67896573069202) to [40.41615589414066, -3.67896573069202] 0.00km
[21:02:39] Walking from (40.41615589414066, -3.67896573069202) to [40.41615589414066, -3.67896573069202] 0.00km
[21:02:41] Walking from (40.41615589414066, -3.67896573069202) to [40.41615589414066, -3.67896573069202] 0.00km
[21:02:42] Walking from (40.41615589414066, -3.67896573069202) to [40.41615589414066, -3.67896573069202] 0.00km
[21:02:44] Walking from (40.41615589414066, -3.67896573069202) to [40.41615589414066, -3.67896573069202] 0.00km
[21:02:46] Walking from (40.41615589414066, -3.67896573069202) to [40.41615589414066, -3.67896573069202] 0.00km
[21:02:47] Walking from (40.41615589414066, -3.67896573069202) to [40.41615589414066, -3.67896573069202] 0.00km
[21:02:49] Walking from (40.41615589414066, -3.67896573069202) to [40.41615589414066, -3.67896573069202] 0.00km
[21:02:51] Walking from (40.41615589414066, -3.67896573069202) to [40.41615589414066, -3.67896573069202] 0.00km
[21:02:52] Walking from (40.41615589414066, -3.67896573069202) to [40.41615589414066, -3.67896573069202] 0.00km
[21:02:54] Walking from (40.41615589414066, -3.67896573069202) to [40.41615589414066, -3.67896573069202] 0.00km
[21:02:56] Walking from (40.41615589414066, -3.67896573069202) to [40.41615589414066, -3.67896573069202] 0.00km
[21:02:57] Walking from (40.41615589414066, -3.67896573069202) to [40.41615589414066, -3.67896573069202] 0.00km
[21:02:59] Walking from (40.41615589414066, -3.67896573069202) to [40.41615589414066, -3.67896573069202] 0.00km
[21:03:01] Walking from (40.41615589414066, -3.67896573069202) to [40.41615589414066, -3.67896573069202] 0.00km
[21:03:03] Walking from (40.41615589414066, -3.67896573069202) to [40.41615589414066, -3.67896573069202] 0.00km
[21:03:04] Walking from (40.41615589414066, -3.67896573069202) to [40.41615589414066, -3.67896573069202] 0.00km
[21:03:06] Walking from (40.41615589414066, -3.67896573069202) to [40.41615589414066, -3.67896573069202] 0.00km
[21:03:08] Walking from (40.41615589414066, -3.67896573069202) to [40.41615589414066, -3.67896573069202] 0.00km
[21:03:09] Walking from (40.41615589414066, -3.67896573069202) to [40.41615589414066, -3.67896573069202] 0.00km
[21:03:11] Walking from (40.41615589414066, -3.67896573069202) to [40.41615589414066, -3.67896573069202] 0.00km
[21:03:13] Walking from (40.41615589414066, -3.67896573069202) to [40.41615589414066, -3.67896573069202] 0.00km
[21:03:14] Walking from (40.41615589414066, -3.67896573069202) to [40.41615589414066, -3.67896573069202] 0.00km
Problem seen in this commit: 9a29c0f  (DEV)

Getting this same error after just doing "git pull"

Same here:
[20:05:25] Walking from (51.4843979, -0.3015578) to [51.4843979, -0.3015578] 0.00km
[20:05:27] Walking from (51.4843979, -0.3015578) to [51.4843979, -0.3015578] 0.00km
[20:05:28] Walking from (51.4843979, -0.3015578) to [51.4843979, -0.3015578] 0.00km
[20:05:30] Walking from (51.4843979, -0.3015578) to [51.4843979, -0.3015578] 0.00km
[20:05:32] Walking from (51.4843979, -0.3015578) to [51.4843979, -0.3015578] 0.00km
[20:05:33] Walking from (51.4843979, -0.3015578) to [51.4843979, -0.3015578] 0.00km
[20:05:35] Walking from (51.4843979, -0.3015578) to [51.4843979, -0.3015578] 0.00km
[20:05:36] Walking from (51.4843979, -0.3015578) to [51.4843979, -0.3015578] 0.00km
[20:05:39] Walking from (51.4843979, -0.3015578) to [51.4843979, -0.3015578] 0.00km
[20:05:40] Walking from (51.4843979, -0.3015578) to [51.4843979, -0.3015578] 0.00km

Is there a simple command with git perhaps that would allow us to downgrade or return to the previous commit?

I can confirm this bug!

I can also see the above happening on the latest dev build

To revert from the latest pull to a previous state:
git reset --hard xyxyxyxy
where xyxyxyxy is found by doing
git reflog

if you do git reset --hard you will probably loose your config files. A git checkout hash, where hash is the commit hash you can get from the git log command, should work as well and leave your configs untouched

Well at least 434cb3a was working OK for me and thanks for the tip on how to revert back!

@buettner123: good idea. Cheers. :)

Tried using the reset --hard method (did move out my config.ini from the directory first) but I just receive this:
(PokemonGo-Bot) xxx-MacBook-Pro:PokemonGo-Bot xxx$ git reset --hard 434cb3a HEAD is now at 434cb3a Fix transfer worker not triggered for last pokemon (#1664)

Nevermind, it worked anyways and now back to commit 434cb3a

git reset --hard won't affect your config files. Config files aren't tracked by git. Unless you are directly using the config.json.example without having renaming it (shame)

Is your bag full, or almost full? It disables forts if it is full. So just empty it in phone app, or set up item_filter

@DayBr3ak: my bad, untracked files are indeed not affected by git reset --hard.
@Simbe90: just fyi about the message you got from git: it said that your HEAD now points to the commit 434cb3a and all tracked files got reverted to that commit and that was exactly what you wanted it to do

Can confirm latest dev build won't work but https://github.com/PokemonGoF/PokemonGo-Bot/commit/aff8e76fdeef738707af23c9fe0fb33336597c12 works :+1:

did the git reset --hard 434cb3a command
is there another command you have to run to get it to downgrade the files as i still have the same problem?

Mine navigates alright (latest dev), but wrong location data is being sent to location-username.json so it appears stationary on the map.

I can also confirm that the latest dev d5acc70 works now. I can't comment on the map issue though as I do not use it.
PS. Getting the latest dev after reverting with "git reset --hard" works by just "git pull"?

come to slack chat #help and someone can help you
NOT A BUG


No podspec file was found.

Hey, thanks for the great work!
Whenever I pod install inside ios/ I get this warning:
[!] use_native_modules! skipped the react-native dependency 'agora-rn-uikit'. No podspec file was found.
    - Check to see if there is an updated version that contains the necessary podspec file
    - Contact the library maintainers or send them a PR to add a podspec. The react-native-webview podspec is a good example of a package.json driven podspec. See
    https://github.com/react-native-community/react-native-webview/blob/master/react-native-webview.podspec
    - If necessary, you can disable autolinking for the dependency and link it manually. See
    https://github.com/react-native-community/cli/blob/master/docs/autolinking.md#how-can-i-disable-autolinking-for-unsupported-library

react-native info
System:
Binaries:
Node: 10.15.1 - /usr/local/bin/node
Yarn: 1.21.1 - ~/n/bin/yarn
npm: 6.4.1 - ~/n/bin/npm
Watchman: 4.9.0 - /usr/local/bin/watchman
Managers:
CocoaPods: 1.7.1 - /usr/local/bin/pod
SDKs:
iOS SDK:
Platforms: iOS 13.5, DriverKit 19.0, macOS 10.15, tvOS 13.4, watchOS 6.2
Android SDK:
API Levels: 23, 26, 27, 28, 29
Build Tools: 27.0.3, 28.0.2, 28.0.3, 29.0.0, 29.0.0
System Images: android-26 | Google APIs Intel x86 Atom, android-27 | Google APIs Intel x86 Atom, android-28 | Android TV Intel x86 Atom, android-28 | China version of Wear OS Intel x86 Atom, android-28 | Wear OS Intel x86 Atom, android-28 | Intel x86 Atom, android-28 | Intel x86 Atom_64, android-28 | Google APIs Intel x86 Atom, android-28 | Google APIs Intel x86 Atom_64, android-28 | Google Play Intel x86 Atom, android-28 | Google Play Intel x86 Atom_64, android-29 | Google Play Intel x86 Atom
Android NDK: 19.2.5345600
IDEs:
Android Studio: 3.4 AI-183.54<IP_ADDRESS>52501
Xcode: 11.5/11E608c - /usr/bin/xcodebuild
Languages:
Java: 1.8.0_60 - /usr/bin/javac
Python: 2.7.16 - /usr/bin/python
npmPackages:
@react-native-community/cli: Not Found
react: 16.11.0 => 16.11.0
react-native: 0.62.2 => 0.62.2
npmGlobalPackages:
react-native: Not Found

Thanks.

Hey, can you check if you can use the library still if you just ignore this error?

The library just can't be actually used on iOS.

This library is a pure JS library. It has no native modules and it won't require any podspec file. We'll be removing the android and ios folders in the next update. @davisuga The issue w IOS might probably be around permissions not present not the podspec.


Switcher ignores blocker signs

Info
Please provide the following information:

BkCommonLib Version (/train version): 1.16.3-v2-SNAPSHOT (build: 925)
TrainCarts Version (/train version): 1.16.3-v2-SNAPSHOT (build: 726)
Server Type and Version (/version): git-Paper-655 (MC: 1.13.2)

Bug
Description
The switcher sign is not looking for an alternative route if there is a blocker sign in it.
Expected behaviour
Check if there is a blocker on the path.
Actual behaviour
The switcher sends the train directly to the best track, without considering blocker signs.
Steps to reproduce
Place a train with a destination. The destination to reach is behind that blocker.
Let the train drive over a switcher so he can search for alternative paths because there is a blocker in the way.
Images below: Destination behind the stopper is K1102

Red: Blocker
Blue: Theoretically best alternative path
Green: Switcher
Weird drawn circle in black: Destination sign to reach

Additional Information
Any additional information we should know of? Ehm. I don't think so ✌

It probably can't find it because the alternative path is too long, I do believe there's some kind of limit, don't remember what the limit is though.

The debug stick since 1.16.3 v1-2 should work fine with that, so that's not it. The path finding itself has no limit, it just takes longer to find the other routes when its far away.
Have you tried /train reroute, or crouching (shift) while hitting the rails with the stick to reroute that local area?

Shifting helped (didn't do the general reroute yet). I updated the plugin today and tought because everything is running fine and was new it should do that already automatically.

It only does it automatically when you place and remove switcher signs. Tracking all the track part of a route would be too memory-intensive, so placing down a blocker sign doesn't refresh any previous routes.


[DP-12820] cleanup pipeline by removing unnecessary secrets and commands

Background
This is a followup to DP-12820 to clean up semaphore pipelines. This change removes some secrets that have been
deactivated as well as removes some commands that are set automatically by the semaphore agent, and replaces
two lines make install-vault and mk-include/bin/vault-setup with . vault-setup.
The same change was made for managed semaphore pipelines, this automated PR
should match the changes made in the managed semaphore pipelines.
Actions
This should not affect your pipelines. If the commands match what was made in the managed semaphore pipelines,
and the pr build passes, please merge this change.

@bennettzhu1 not much going on here... ok to close?

@brianstrauch not sure why it was opened, i'll close it


disable ipv6 in Avahi when it's disabled in main.tf

One can disable IPv6 on most VMs with
  ipv6 = {
    enable = false
    accept_ra = false
  }

Even when done so, /etc/avahi/avahi-daemon.conf still contains the line
use-ipv6=yes

leading to a bit slower name resolution by Avahi.
I think this has only a small performance implication - it does not seem to trigger any bugs, as far as I can see.

PR #573 should solve this.

Merged


[Bug]: Tie score not updated on click of the reset score button in rock paper scissors game.

Give a brief about the bug ✍
The number of ties is not reverted back to zero on click of the reset score button.
What is the expected behavior? 🤔
On click of the reset score button the wins ,loses and ties score should be reverted back to zero.
Provide step by step information reproduce the bug 📄
I can make the required changes so that the tie score is changed back to zero on click of the reset score button.
Select program in which you are contributing
GSSoC24
Code of Conduct

[X] I follow CONTRIBUTING GUIDELINE of this project.

Hey @meetarora10 !
Thank you for raising an issue 💗
You can self assign the issue by commenting /assign in comment 😀
Make sure you follow CODE OF CONDUCT and CONTRIBUTING GUIDELINES 🚀
Don’t Forget to ⭐ our GameZone🎮
Make sure you join our Discord🕹

/assign

Hey @meetarora10 ! Thank you so much for your raising the issue💗
It’s all yours, you can come anytime again and make some contributions! 🚀
Alone, we can do little, but together we can do so much! 😇


Scene Activation CC does not create metadata

because there is no interview procedure

@marcelveldt I've looked into this, the problem is as follows:
zwave-js has the concept of static and dynamic metadata. Whenever metadata is exposed to applications, the dynamic part is merged on top of the static one. This means we can define the basic shape of a metadata in the CC implementations and then change states for example during the interview.
Whenever the dynamic part of a metadata is changed, a metadata updated event is emitted with the resulting merged metadata. However this event is not emitted if a value only has static metadata like the scene ID.
What I do in iobroker.zwave2 (and what you should probably do too) is to request the metadata from zwave-js with node.getValueMetadata(valueId) if you don't have any metadata for a value yet. This method is guaranteed to at least return some very basic metadata (ValueMetadata.Any).

@robertsLando you might need to respect that too in z2m


Support napping

Hi
I have started to add some napping support as per https://github.com/jcgoette/baby_buddy_homeassistant/issues/49
This change is related to: https://github.com/babybuddy/babybuddy/pull/504 and https://github.com/babybuddy/babybuddy/issues/503
I am still new and learning. Appreciate your support.
It doesn't appear to be registering naps, and I think it's due to switch.py but I can't figure out how to pass the 'napping' bool. Appreciate your advice.

Hi @lukyjay , thanks for your time and interest. After reading through the discussion on BB repo, I am going to close this issue/PR until any potential design changes are implemented in BB itself.


WIP: Implement building cache_images

Signed-off-by: Chris Evich<EMAIL_ADDRESS>

@edsantiago and @lsm5 if you don't mind, despite this being a WIP I would appreciate feedback on the README.md.  Esp. "The last step" section this PR updates: https://github.com/containers/automation_images/pull/8/files?file-filters[]=.md  Does this seem like an improvement to the process/workflow?  For example, if you had to update a podman or buildah CI image.
Also, I haven't documented it yet, but the Makefile here does allow running ALL the packer builds locally.  So it's also possible to selectively build one Distro or version, e.g. only Ubutnu.  The only required input is a credentials file (which I can provide as needed).

w00t! entire build-chain is working & producing images.


Batched MSE

Use some batching (like for example using several episodes and not just one) for computing MSE


Arabic Language Support

I am working with react-to-pdf library and convert my report to PDF. My text data is in Arabic language. My report exported successfully into pdf but text become like this
!(https://github.com/ivmarcos/react-to-pdf/assets/120670791/014af2bc-6375-414d-bed8-dee3e93819aa)

Hi @shoaibanjumuae , frankly I have no idea. This is most probably related to the html2canvas package that is used internally in the package. I took a quick look in their repo and saw some issues related to arabic fonts: https://github.com/niklasvh/html2canvas/issues?q=is%3Aissue+is%3Aopen+arabic
Maybe some is related to this, but I haven't seen any exact match to this. I'll keep this issue open to see if anyone has any better idea.


System.loadLibrary("androidmp3recorder"); crash

Hello.
When calling the method start(), I get the following crash:
java.lang.UnsatisfiedLinkError: dalvik.system.PathClassLoader[DexPathList[[zip file "/data/app/xxx-J_ntdkKz_3gMNhfiyYCpBw==/base.apk"],nativeLibraryDirectories=[/data/app/xxx-J_ntdkKz_3gMNhfiyYCpBw==/lib/arm64, /data/app/xxx-J_ntdkKz_3gMNhfiyYCpBw==/base.apk!/lib/arm64-v8a, /system/lib64, /system/product/lib64]]] couldn't find "libandroidmp3recorder.so"
Could you help me please?
Thank you.

I was using the version 1.0.0 instead of the version 1.0.1.
Please fix the README version if you don't mind.
Thanks!


Fix perf tests currently broken

The interface for the Init method of state stores changed and that broke our perf tests
See: https://github.com/dapr/dapr/actions/workflows/dapr-perf.yml

@dapr/maintainers-dapr please see this as our perf tests are currently broken

/ok-to-perf

UT seems flaky :(


'ascii' codec can't decode byte 0xd1 in position 0: ordinal not in range(128)

Hi,
When I ran the command 'python UDT.py --model ../train/work/checkpoint.pth.tar', some mistakes occurred:
Traceback (most recent call last):
File "UDT.py", line 122, in
net.load_param(args.model)
File "/home/wy/UDT_pytorch/track/net.py", line 64, in load_param
checkpoint = torch.load(path)
File "/home/wy/.pyenv/versions/3.6.3/lib/python3.6/site-packages/torch/serialization.py", line 387, in load
return _load(f, map_location, pickle_module, **pickle_load_args)
File "/home/wy/.pyenv/versions/3.6.3/lib/python3.6/site-packages/torch/serialization.py", line 574, in _load
result = unpickler.load()
UnicodeDecodeError: 'ascii' codec can't decode byte 0xd1 in position 0: ordinal not in range(128)
What can I do to fix this problem?
Thanks

You can try to add the following code at the beginning of net.py:
from functools import partial import pickle pickle.load = partial(pickle.load, encoding="latin1") pickle.Unpickler = partial(pickle.Unpickler, encoding="latin1")

It works，thank you very much.

I add the code in net.py, but there has other mistake occurs:
Traceback (most recent call last):
File "E:/Person_Tracking/TA/_Siamese/UDT/UDT_pytorch/track/UDT.py", line 123, in
net.load_param(args.model)
File "E:\Person_Tracking\TA_Siamese\UDT\UDT_pytorch\track\net.py", line 71, in load_param
if 'module' in state_dict.keys()[0]:  # train with nn.DataParallel
TypeError: 'odict_keys' object does not support indexing
What can I do to fix this problem?
Thanks

you can modify if 'module' in state_dict.keys()[0]: to if 'module' in list(state_dict.keys())[0]: @Clannad000000


pypy support

@rfk do you know which freezers work with pypy? I want to add some documentation in this area.

I don't sorry; I've never tried to make a frozen app with pypy as its interpreter.
(The code in esky can use pypy for compiling its bootstrap env, but that's a while 'nother story and I'm not at all sure it still works with latest upstream pypy)

So if you have pypy installed esky will try and compile the bootstrap.env with pypy? Is the purpose of this to increase speed? Is this a useful feature we should support/ document?

So if you have pypy installed esky will try and compile the bootstrap.env with pypy

There's a special option in setup.py to enable it, something like compile_bootstrap_exe.

Is the purpose of this to increase speed?

Mostly it's to decrease file size; it means you can have just a very small stub exe in the bootstrap env, rather than a copy of a whole python interpreter.

Is this a useful feature we should support/ document?

Yes, but first we should confirm whether it still works at all :-)

Unfortunately this project is no longer actively maintained, so I'm going to move it into archive mode:
https://rfk.id.au/blog/entry/archiving-open-source-projects/


fix(datepicker): check if getter.assign is function

Closes #3155, #3345

Travis seems to be busted. Some tests failed that are not related to this PR. @RobJacobs do you know anything about this? You're the last one who touched the master branch.

@rvanbaalen The package.json had the angular dependency as ^1.3.15 so it was pulling in the recently released 1.4 version.  I checked in a change with the dependency set to >=1.3.x. although there may be a better version syntax I should have used.


Improve UI of the web application

Is your feature request related to a problem? Please describe.
The front end appears to be very basic
Describe the solution you'd like
A user friendly and eye-catchy yet classy look of the website
Describe alternatives you've considered
A change in color palette.

please assign me under SSOC

Go on.

Are you still on it ?

Yaaa, I am. (I’ll create a pr by the end of this weekend for sure)

Are you still on it ?

Yes, so sorry for the delay. I’m using react for the first time so it’s taking longer than expected.

PrivatePing does not use react.

I am using react for the front end.

We're using simple css and javascript.


(Brand) Hp and Lenovo Page

To be completed

Low fi design have been coded

I made little  readjustments

I added high-fi design to the pages

https://www.figma.com/file/P9UFnIxyfuvMkKNkKUWh76/Team-28_Price-Compare?node-id=454%3A102


Nginx + w3tc page cache - fires php even though page is cached

EDIT:

When using w3tc, you should use the "Cache SSL (https) requests" option, even though it says "Cache SSL requests (uniquely) for improved performance.", making you think that it caches request, only not uniquely. At least in my test system, it doesn't.
Could be related to the error message that appears when enabling debug mode for w3tc page cache:
"W3 Total Cache error: It appears Page Cache URL rewriting is not working. Please verify that all configuration files are included in the configuration file (and that you have reloaded / restarted nginx).
Unfortunately disk enhanced page caching will not function without custom rewrite rules. Please ask your server administrator for assistance. Also refer to the install page for the rules for your server.
Technical info"

After your SSL runs well and w3tc configured, you need to update the appropriate conf files - "w3tc.conf" and "w3tc-php7.conf" files to reflect the fact that the cached files will now have "_ssl" suffix.

I guess the ee script does that automatically, but the ee LE script doesn't work lately. Perhaps it will be fixed with next versions?

Testing a site running on a Linode. It works well with w3tc page cache enabled:
0. Page cache is using the "Disk : Enhanced" option

Cached pages are created and they are ok
However, accessing them causes PHP7.0 processes to fire (lots of them, for high traffic)
Tried to access the cached html file directly - works well and doesn't fire PHP, as should be
Didn't change nginx conf configuration, only added ssl stuff in a different file under the /var/www/[site]/conf/nginx
Edit: 5. Tested with a clean page (literally only a div element, no php, head element or others) - again, cached html version created, but again, php7.0 processes are fired. Makes no sense

What's going on? why is the php fired up?
Tried other sites on my linode, and it happens there too
Any clue? How can I trace the source of the problem?
Requested info below:
- [ ] lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description:    Debian GNU/Linux 8.8 (jessie)
Release:        8.8
Codename:       jessie
- [ ] ee -v
EasyEngine v3.7.4
- [ ] ee info
NGINX (1.10.3):
user                             www-data
worker_processes                 auto
worker_connections               4096
keepalive_timeout                30
fastcgi_read_timeout             300
client_max_body_size             100m
allow                            <IP_ADDRESS>
PHP (7.0.20-1~dotdeb):
user
expose_php                       Off
memory_limit                     128M
post_max_size                    100M
upload_max_filesize              100M
max_execution_time               300
Information about www.conf
ping.path                        /ping
pm.status_path                   /status
process_manager                  ondemand
pm.max_requests                  500
pm.max_children                  100
pm.start_servers                 20
pm.min_spare_servers             10
pm.max_spare_servers             30
request_terminate_timeout        300
xdebug.profiler_enable_trigger   off
listen                           <IP_ADDRESS>:9000
Information about debug.conf
ping.path                        /ping
pm.status_path                   /status
process_manager                  ondemand
pm.max_requests                  500
pm.max_children                  100
pm.start_servers                 20
pm.min_spare_servers             10
pm.max_spare_servers             30
request_terminate_timeout        300
xdebug.profiler_enable_trigger   on
listen                           <IP_ADDRESS>:9001
MySQL (10.1.25-MariaDB) on localhost:
port                             3306
wait_timeout                     600
interactive_timeout              28800
max_used_connections             101
datadir                          /var/lib/mysql/
socket                           /var/run/mysqld/mysqld.sock
my.cnf [PATH]                    /etc/mysql/conf.d/my.cnf
- [ ] wp --allow-root --info
PHP binary:     /usr/bin/php7.0
PHP version:    7.0.20-1~dotdeb+8.2
php.ini used:   /etc/php/7.0/cli/php.ini
WP-CLI root dir:        phar://wp-cli.phar
WP-CLI packages dir:
WP-CLI global config:
WP-CLI project config:
WP-CLI version: 0.24.1

@eddr w3tc has not been actively supported anymore. Can you try using --wpredis  cache?
https://easyengine.io/blog/easyengine-3-3-full-page-redis-cache/

Rahul, it's quite old. It works now with the changes I've mentioned.
Why is W3TC not supported? I don't want everything to be kept in memory, in my case

If I may ask, please consider also supporting --wpsc.

I think the consolidation of options is a good move especially for the community to have an easier time crowd sourcing support for each other. @rahul286 what option(s) 1 or 2 are your leaning towards or decided on at the moment or will that be decided at a later date.

@sleepycommerce I was planning to get a new one based on memcache. The idea is to use batcache https://wordpress.org/plugins/batcache/ to write to memcache and then use nginx core module to read from memcache http://nginx.org/en/docs/http/ngx_http_memcached_module.html
This way there will be no dependencies on third-party nginx modules.
Batcache is maintained by Automattic and is used on WordPress.com.

To be honest - all full page caching have similar performance. I see it's binary. If Nginx can "get" a page without getting PHP & MySQL involved - it matters less nginx do it using redis, fastcgi-cache or WordPress plugins.

@rahul286 Thx for replying
batcache hasn't been maintained for quite some time..
And also, I still don't think that saving everything in memory is a good path. It's limited and SSDs today are relatively fast..

@rahul286 I think it's a desirable direction given it's scalable to distributed setups. but as @eddr mentioned it hasn't been updated for a minute on .org however The github has alot more activity which is good and as automatic relies on it for .com "supercache" it should be fairly safe to say it will be around or easier to to fork and maintain if it's the only setup.
But maybe just no cache or cache as options for those who would like to integrate their own preferences. I still would lean most on one cache setup to benefit the community support over many.

@sleepycommerce thanks for the heads up. From I read in their github page, it's not the same thing at all.. I was talking about object cache, not page cache.


Don't Merge! PR real time test for target branch full build

Docs Build status updates of commit d85b941:
:clock10: Pending: waiting for processors (13 builds ahead of you)
:warning: Docs Build is busy, currently there are 13 builds ahead of this one, for more information you can view the Build queue graph on the Docs Portal.

Docs Build status updates of commit d85b941:
:clock10: Full build: the average full build time is 7 min(s) 47 sec(s), this is based on the last 30 build(s) for this repository.

Docs Build status updates of commit d85b941:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

docs-ref-conceptual/testing.md
:white_check_mark:Succeeded
View (azure-cli-latest) View (azure-cli-2017-03-09-profile) View (azure-cli-2018-03-01-hybrid)

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching in the Docs contributor and Admin GuideSee the frequently asked questionsPost your question in the Docs support channel


Add integrity check to StringIdMap

@czentgr just following up on this. In the issue here:https://github.com/prestodb/presto/issues/20019#issuecomment-1815294535 you mentioned that the issue is not reproducible anymore. Is this change is still relevant?
cc: @aditi-pandit @majetideepak


requireNativeComponent: "SRSRadialGradient" was not found in the UIManager.

Hi,
I am trying to install this package to my react native, but I am getting the following error:
requireNativeComponent: "SRSRadialGradient" was not found in the UIManager.
After installing in the library, I executed pod install int the ios directory but it did not add SRSRadialGradient as a dependency. I believe there is an issue with autolinking?
Here is an example repro. If you try to install and then run pod install you'll see that it doesnt add package to the podfile and you'll get the error specified above when trying to use the component

+1 same happens to me.


einshape requirement use of git://

Hi Rudy -
I was just trying to pip install a local clone of this repo and got this error:
(venv3.10) mfe@Michaels-MacBook-Air robustness_analysis % python -m pip install -e jax_verify
Obtaining file:///Users/mfe/code/robustness_analysis/jax_verify
  Preparing metadata (setup.py) ... done
Collecting einshape@ git+git://github.com/deepmind/einshape.git
  Cloning git://github.com/deepmind/einshape.git to /private/var/folders/cq/gg1tn9g54pn2vg_fh99fh3_00000gn/T/pip-install-s6x2khvr/einshape_5dc538cc56a94e73a5e1c2474dedfd11
  Running command git clone --filter=blob:none --quiet git://github.com/deepmind/einshape.git /private/var/folders/cq/gg1tn9g54pn2vg_fh99fh3_00000gn/T/pip-install-s6x2khvr/einshape_5dc538cc56a94e73a5e1c2474dedfd11
  fatal: unable to connect to github.com:
  github.com[0: <IP_ADDRESS>]: errno=Operation timed out

  error: subprocess-exited-with-error

  × git clone --filter=blob:none --quiet git://github.com/deepmind/einshape.git /private/var/folders/cq/gg1tn9g54pn2vg_fh99fh3_00000gn/T/pip-install-s6x2khvr/einshape_5dc538cc56a94e73a5e1c2474dedfd11 did not run successfully.
  │ exit code: 128
  ╰─> See above for output.

  note: This error originates from a subprocess, and is likely not a problem with pip.
error: subprocess-exited-with-error

× git clone --filter=blob:none --quiet git://github.com/deepmind/einshape.git /private/var/folders/cq/gg1tn9g54pn2vg_fh99fh3_00000gn/T/pip-install-s6x2khvr/einshape_5dc538cc56a94e73a5e1c2474dedfd11 did not run successfully.
│ exit code: 128
╰─> See above for output.

note: This error originates from a subprocess, and is likely not a problem with pip.

I fixed this by changing the einshape line in requirements.txt to use https:// instead of git:// per this post.

hi, I'm having the same issue. Had to clone the repo and manually make the change to requirements.txt in order to pip install (the version on PyPi doesn't work with more recent versions of jax)


unable to use chart in horizontal scroollview.

if i add chart in horizontal scroll view chart disappears.

If you define a default width the chart will appear

Thanks for your response,
Solved this issue.
On Mon, Apr 1, 2019, 12:50 AM João Farinhote<EMAIL_ADDRESS>wrote:

If you define a default width the chart will appear
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/aloisdeniel/Microcharts/issues/108#issuecomment-478374516,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AXEqtLVU01yv9LcnAaEkxL1h2is6A7XMks5vcRGXgaJpZM4U5dlE
.

Hi I have the same issue on Android. Used in normal ScrollView it shows fine. When I change this to HorizontalScrollView it isn't shown.
What is the default width you mention?

Hi
I believe any valid width will do.

Hi,
I am writing to you to request your participation in a brief survey .
The survey is very brief and will only take about 5 minutes to complete.
Please click the link below to go to the survey Web site
https://www.surveymonkey.com/r/Y5HN728
Regards,
Junaid

Done brother!!
On Tue, Mar 17, 2020, 10:23 AM malik junaid<EMAIL_ADDRESS>wrote:

Hi,
I am writing to you to request your participation in a brief survey .
The survey is very brief and will only take about 5 minutes to complete.
Please click the link below to go to the survey Web site
https://www.surveymonkey.com/r/Y5HN728
Regards,
Junaid

--
Zeeshan Sumar_ibexfppk from FoodPanda
ref:_00Dw0l3C7._5001r2mPphH:ref


NUIPreprocessor added

Stylesheets are preprocessed before fed into tokenizer.
The preprocessing means:

dropping comments (block and single line comments are handled)
handling imports: @import ‘my.file.nss’
The autoupdate feature is modified too, in order to monitor the main file and it's dependencies too.

The main goal was to get able splitting my stylesheets into smaller ones,
like collecting the colours used into one file, buttons into an other and so on.
Drawbacks:

the preprocessor uses NSRegularExpression to check the input which
could be slow if intensively used, however in this case we are checking
for 3 simple patterns.
the location-related token properties got broken due the imports,
however they aren’t used on NUI-level at all.

Hey guys,
Can someone take a look at this? Import would be super useful.


Ports not published to the service name ip when using a network plugin (weave)

When I deploy this v3.7 docker-compose.yml stack onto a two node docker <IP_ADDRESS> swarm cluster using the overlay network it works as expected -- service names can be used on the network and ports are accessible.
https://gist.github.com/jamshid/bf5dcdb0ae1b505a636b33ca5ebfba4b
Unfortunately it doesn't work when using the "weave" network plugin:
NETWORK_DRIVER=weaveworks/net-plugin:latest_release docker stack deploy -c ./docker-compose.yml voteapp

docker run -ti --network voteapp_voteapp centos curl --head http://result-app:80 http://voting-app:80

I filed https://github.com/weaveworks/weave/issues/3734 but they think it is probably a change or bug with docker or swarm network plugins. In the similar issue https://github.com/weaveworks/weave/issues/3382 some people claimed downgrading to 18.03 fixed the problem, so maybe something broke with network plugins 18.06?
My example yml is based on the common voting app sample https://github.com/dockersamples/example-voting-app and should be easy to deploy then test with the curls in my gist.
Is there any other network plugin I can use besides "overlay" or "weave" to try to narrow down the problem? Is there anything else I could provide to help?

@GordonTheTurtle  @thaJeztah : any plans of fixing this "key" feature in upcoming release?


config: add typeorm test to tidb merged ci

Wait PR https://github.com/PingCAP-QE/ci/pull/2492 merged.

/cc wuhuizuo @purelind


fix for uncomparable errors in errors pkg

Prevents uncomparable errors from creating panics when checking for moc code.
Added tests to ensure uncomparable errors are handled correctly.

/azp run


Upgrade to c-ares 1.31

This new release contains numerous bug fixes since the previous version. It also contain a performance increase for the purpose of rTorrent. DNS queries are now cached for 1 hour to avoid repetitive lookups. This will improve TCP tracker update performance.

The build logs have shown that curl v8.5.0 was successfully built with c-ares v1.31 and AsynchDNS is enabled.
2024-06-26T15:37:15.0816659Z #98 7.728 curl 8.5.0 (Linux) libcurl/8.5.0 OpenSSL/3.1.5 zlib/1.3.1 brotli/1.1.0 zstd/1.5.5 c-ares/1.31.0
2024-06-26T15:37:15.0817523Z #98 7.728 Release-Date: 2023-12-06
2024-06-26T15:37:15.0818487Z #98 7.728 Protocols: dict file ftp ftps gopher gophers http https imap imaps mqtt pop3 pop3s rtsp smb smbs smtp smtps telnet tftp
2024-06-26T15:37:15.0820106Z #98 7.728 Features: alt-svc AsynchDNS brotli HSTS HTTPS-proxy IPv6 Largefile libz NTLM SSL threadsafe TLS-SRP UnixSockets zstd


New command: spo applicationcustomizer list

Usage
spo applicationcustomizer list [options]
Description
Get a list of application customizers that are added to a site.
Options

Option
Description

-u, --webUrl <webUrl>
The url of the site.

-s, --scope [scope]
Scope of the application customizers. Allowed values: Site, Web, All. Defaults to All.

Examples
Retrieves a list of application customizers.
m365 spo applicationcustomizer list --webUrl https://contoso.sharepoint.com/sites/sales

Additional Info
While developing we want to reuse the getCustomActions function of the spo util class.
We can use the shared code to only query customactions with a location value of ClientSideExtension.ApplicationCustomizer.

Before we hand over the issue to implementation, let's extend the spec with how are we going to determine the type of each custom action so that we return only app customizers.

Also, let's define list of properties displayed by default in the text output mode

I've updated the specs with a description of the route to take: add a util class to retrieve custom actions by location.
@waldekmastykarz, question about this new spo web applicationcustomizer command group: we've added a scope option to be able to get application customizers on the web level or site level. However, it's a bit vague in this context that this command is a subcommand of spo web. Should we not create all these commands on the root spo level if we're using the scope option everywhere?

Following customaction command naming convention, we should indeed include applicationcustomizer commands directly under spo. Good catch!

We can now pick this up due to the implemented util class.

Would love to work on this one

Thanks Nico!


Fetch schema to validate json

Fix https://github.com/mapbox/HecateJS/issues/37
Add ajv module to validate features according to the JSON schema before importing data into Hecate.
@mapbox/search

Currently, I'm unable to get the schema.
if I run HECATE_USERNAME=x HECATE_PASSWORD=y  ./cli.js schema get I get an error
{"statusCode":406,"headers":{"server":"GitHub.com","date":"Wed, 13 Nov 2019 18:42:14 GMT","content-type":"application/json","transfer-encoding":"chunked","connection":"close","status":"406 Not Acceptable"...}

I'm able to get the schema if I pass a token so we might want to prompt for this information.
cc./ @ingalls @miccolis

This is now starting & cachine the schema as expected, however upon attempting to validate a feature against the schema it runs into a max callstack error
schema $id ignored http://json-schema.org/draft-07/schema#
/home/null/Development/HecateJS/node_modules/ajv/lib/compile/resolve.js:239
  traverse(schema, {allKeys: true}, function(sch, jsonPtr, rootSchema, parentJsonPtr, parentKeyword, parentSchema, keyIndex) {
                                            ^

RangeError: Maximum call stack size exceeded
    at /home/null/Development/HecateJS/node_modules/ajv/lib/compile/resolve.js:239:45
    at _traverse (/home/null/Development/HecateJS/node_modules/json-schema-traverse/index.js:65:5)


Updated Cardinal Assets and Gemspec for Rails 5.

I'm currently working on a project for school with Rails 5 and I didn't wanna use bootstrap again for the styling. So I found cardinal and this gem, which wasn't ready for Rails 5 yet. So I updated the Gemspec to support all new dependencies. In the same move, I updated the files of cardinal to their latest release 3.6.1.

please give this guy write access so he can maintain the gem !!!!

Guess I'll this one. PR is outdated :)


Write black-box tests for DefaultAbly.connect

These document the current behaviour of this method.
I wrote them having only seen the Ably interface (which DefaultAbly implements), and knowing the dependencies that DefaultAbly has.
I intentionally did not look at the code whilst writing these tests because I wanted to limit myself to writing test cases based on scenarios that I could imagine might occur, instead of ones based on logic that I know to exist.
Once I’ve written tests like this for the whole class, then I’d like to look at its implementation and add any further test cases for logic that wasn’t clear from the public interface.
This is part of #869.

I have to admit that I had mixed feelings about the DefaultAblyTestScenarios object, but after familiarizing myself with it the reasoning about particular test cases is much easier with it 👍 Though, it still might be difficult at first to understand what's going on in those tests 😉

I agree with you 100%. I find both reading and writing tests exceptionally difficult in general! And I'm constantly flipping back and forth between "the test cases should be very explicit" (which then leads to super long test cases which completely obscure what you're actually testing with a load of boilerplate - see the ably-cocoa tests) and "the test cases should be concise" (where you end up with these test scenario methods which have a load of code and require you to read them).
I've aimed to ease some of the issues with the latter approach here by writing lots of prose - the test scenario method has a human-readable Given / When / Then description of exactly what it's testing, as does every single test case. So people looking at the DefaultAblyTests file don't need to understand the scenario code if they don't want to.

I'm going to convert this to a draft since I think I might make some changes to it as part of my continued work on #878.

@davyskiba @KacperKluka I've pushed some changes (just the ones to DefaultAblyTestScenarios.kt; the other changes are from main). It generalises some of the stuff that this PR adds, so that I can use it in subsequent tests. There are no changes in terms of content.

Also pushed a minor change, simplifying syntax used in docstring comments for if / when.


企业问些设置的时候提示openapi回调地址不正确

终端提示：
[2023-04-26 11:12:50,650] ERROR in app: Exception on /wechat [GET]
Traceback (most recent call last):
File "/usr/local/lib/python3.8/dist-packages/flask/app.py", line 2190, in wsgi_app
response = self.full_dispatch_request()
File "/usr/local/lib/python3.8/dist-packages/flask/app.py", line 1486, in full_dispatch_request
rv = self.handle_user_exception(e)
File "/usr/local/lib/python3.8/dist-packages/flask/app.py", line 1484, in full_dispatch_request
rv = self.dispatch_request()
File "/usr/local/lib/python3.8/dist-packages/flask/app.py", line 1469, in dispatch_request
return self.ensure_sync(self.view_functions[rule.endpoint])(**view_args)
File "/home/bot-on-anything-1.1.0/channel/wechat/wechat_com_channel.py", line 27, in handler_msg
return WechatEnterpriseChannel().handle()
File "/home/bot-on-anything-1.1.0/channel/wechat/wechat_com_channel.py", line 72, in handle
echostr = self.crypto.check_signature(signature, timestamp, nonce, echostr)
File "/usr/local/lib/python3.8/dist-packages/wechatpy/enterprise/crypto.py", line 23, in check_signature
return self._check_signature(
File "/usr/local/lib/python3.8/dist-packages/wechatpy/crypto/init.py", line 60, in _check_signature
pc = crypto_class(self.key)
File "/usr/local/lib/python3.8/dist-packages/wechatpy/crypto/base.py", line 21, in init
self.cipher = WeChatCipher(key)
File "/usr/local/lib/python3.8/dist-packages/wechatpy/crypto/cryptography.py", line 25, in init
Cipher(
TypeError: init() missing 1 required positional argument: 'backend'
<IP_ADDRESS> - - [26/Apr/2023 11:12:50] "GET /wechat?msg_signa. TA%3D%3D HTTP/1.1" 500 -

#306
看下这个。

能用了，谢谢


[Enhancement] Is there a way to config nvim-notify

I mainly run tests in the IEx shell when I develop Elixir projects, It's super fast, but it's easy to miss the notifications, so I want to use https://github.com/rcarriga/nvim-notify to notify me after the test is finished.
How do I archive this?
FYI: https://github.com/jfpedroza/neotest-elixir/pull/23

You can write a custom consumer for this.
  neotest.setup({
    consumers = {
      notify = function(client)
        client.listeners.results = function(adapter_id, results, partial)
          -- Partial results can be very frequent
          if partial then
            return
          end
          require("neotest.lib").notify("Tests completed")
        end
        return {}
      end,
    },

You could check the results to change the message.
I'd be open to PRs for a built-in consumer with a more fleshed out API if you're interested or I may get around to implementing myself at some stage :sweat_smile:

I'm interested in what you said about a fleshed out API.

Well I'm open to ideas :smile:
Some potential niceties:

Configuring notifications for failures only
Notifying with the error short message if present when a single test is run. Generally if I'm running a single test, I'd like to see the result quickly so that could be a useful way of doing it.
Changing the level based on if failures happened or not

Cool, I like these ideas.

Maybe all there's needed is an example in the README. The API that's there in place along with its type hints is super clear and easy to write anything one might like, thanks @rcarriga!


Pascal-style strings

Before we do string indexing, pascal-style strings should be implemented.
However, before we do, we should wait until modules are fully working so we can have a fmt-like library. This is because we can't use pascal-style strings with printf, so we need Ark-specific functions.

@MovingtoMars
Are we implementing these natively in the compiler, or in the standard library?

I think I'd be happy with it in the standard library with a char_at func rather than natively in the compiler. And if we do implement it in the stdlib, is there any point of the issue #613 existing, since it's literally just a function?

I think pascal-style strings should be native. Functions for working on them would go in the stdlib (eg, getting rune by index.)

In fact, we could just do type string []u8;

I would also like to add that native pascal-style strings would give us the opportunity to optimise out many bounds-checks. If it was a library, that wouldn't be possible.

@MovingtoMars Hmm, okay I think I agree with you here.


seed file day-before-today logic doesn't seem to be working right

It appears specifically to be an issue with the fallback logic -- if a file doesn't exist on S3, it should fall back to local, but that doesn't appear to be happening. It should be a simple fix but I should also write some tests for that.


wrong connection

Describe the bug
A clear and concise description of what the bug is.
when 2 spaces use the same connection name, when the job is run , the first connection is taken and not the real connection
make sure when connection is looked up the target space is being used

Solved and implemented


s390x: Implement tls_value

Implement the tls_value for s390 in the ELF general-dynamic mode.
Notable differences to the x86_64 implementation are:

We use a __tls_get_offset libcall instead of __tls_get_addr.
The current thread pointer (stored in a pair of access registers)
needs to be added to the result of __tls_get_offset.
__tls_get_offset has a variant ABI that requires the address of
the GOT (global offset table) is passed in %r12.

This means we need new libcall entries for __tls_get_offset and
the GLOBAL_OFFSET_TABLE symbol.  The latter is a bit weird in
that it is not actually a function, so "libcall" seems a bit
inappropiate.  But there currently is no way, apart from the
libcall mechanism, so refer to a well-known global symbol by name.
We also need to emit a relocation on a symbol placed in a
constant pool, as well as an extra relocation on the call
to __tls_get_offset required for TLS linker optimization.
Needed by the cg_clif frontend.

#4546 introduces a KnownSymbol mechanism, which sounds like it would be useful here.

#4546 introduces a KnownSymbol mechanism, which sounds like it would be useful here.

Looking at this, I'm wondering why the whole mechanism of allowing names to be replaced externally is even necessary here.  I can see where this is useful for libcalls, in case you want to substitute another library.  But for something like _GLOBAL_OFFSET_TABLE_, that name is defined by the ABI and hard-coded into the linker, there is no way to override this anyway.
So maybe it would be simpler to just add a feature to allow the backend to simply hard-code a symbol name?

bjorn3 mentioned that we may need it in the JIT to perform TLS lookups

bjorn3 mentioned that we may need it in the JIT to perform TLS lookups

I'm still not sure I see it - at least in the case of _GLOBAL_OFFSET_TABLE_, this is not a "real" symbol either way.  When creating an object file used by the system linker, the name has to be exactly this string as specified by the ABI, otherwise the required special processing will not trigger in the linker.  If we re-implement linker functionality in the JIT, the JIT will simply have to perform that special processing itself, which should not involve any symbol name at all.   There is no scenario I can envision where it makes sense to replace a reference to _GLOBAL_OFFSET_TABLE_ with a reference to some symbol with another name.

In the JIT no object files are created and it is not possible to use the libc tls implementation. My idea has been to intercept the libc function call to get the tls address and implement it in the jit, entirely avoiding libc in the process (except for a single native tls access to get a list of all jit tls values for the current thread)

Reading the pr description it doesn't seem like the way I was planning to implement it on x86_64 will work on s390x, as on s390x the generated code already accesses the tls register, while on x86_64 this is left for the libcall that can be replaced.

Reading the pr description it doesn't seem like the way I was planning to implement it on x86_64 will work on s390x, as on s390x the generated code already accesses the tls register, while on x86_64 this is left for the libcall that can be replaced.

I think this also applies to the COFF TLS model, we never perform any libcall's, its all relocations. And if we want to implement it in the JIT we are also going to need to handle that separately in the jit linker right?

I think this also applies to the COFF TLS model, we never perform any libcall's, its all relocations.

Even on Windows it would be possible to use ELF tls in the JIT.

And if we want to implement it in the JIT we are also going to need to handle that separately in the JIT linker right?

At least a prototype can be done outside of the jit in cg_clif itself.

Reading the pr description it doesn't seem like the way I was planning to implement it on x86_64 will work on s390x, as on s390x the generated code already accesses the tls register, while on x86_64 this is left for the libcall that can be replaced.

So the way GD TLS works on s390x is that you 1) have a constant pool entry that contains a relocation which the linker will resolve to the GOT offset of a pair of GOT slots holding the TLS module index and offset for the target symbol;   2) load this GOT offset and pass it to __tls_get_offset, which will load the module index and offset from the GOT, and return the TLS section offset of the requested symbol, and 3) add the value of the current thread pointer to that TLS offset.
There is a linker optimization in play, for the case where you don't need the full general-dynamic support, that will do two things: 1) change the relocation on the constant pool entry to directly place the TLS section offset of the target symbol there (instead of the GOT offset of the module/offset pair), and replace the call to __tls_get_offset with a no-op.   This will lead the generated code to effectively, instead, load the TLS section offset from the constant pool and add the current thread pointer, with no libcall involved.
W.r.t. implementing TLS in the JIT, I guess that depends to a large extent on what exactly should be supported.   But the fact that we add the thread pointer in itself doesn't change much - if nothing better is possible, you can always implement __tls_get_offset in terms of your __tls_get_addr implementation and just subtract the current thread pointer before returning.
This will require overloading __tls_get_offset (and __tls_get_addr) - but those are (and should remain) normal libcalls that can already be overloaded by the JIT.
This discussion is about _GLOBAL_OFFSET_TABLE_, which is needed here as parameter to __tls_get_offset.   (Of course there can also be other uses of _GLOBAL_OFFSET_TABLE_ unrelated to TLS.)   This has to be handled by the JIT itself, because whatever value is used as _GLOBAL_OFFSET_TABLE_ must match the GOT start that is also used to resolve GOT-relative relocations.   I don't see any way to implement _GLOBAL_OFFSET_TABLE_ by just redirecting to some other symbol provided outside the JIT.

This discussion is about GLOBAL_OFFSET_TABLE, which is needed here as parameter to __tls_get_offset. (Of course there can also be other uses of GLOBAL_OFFSET_TABLE unrelated to TLS.) This has to be handled by the JIT itself, because whatever value is used as GLOBAL_OFFSET_TABLE must match the GOT start that is also used to resolve GOT-relative relocations. I don't see any way to implement GLOBAL_OFFSET_TABLE by just redirecting to some other symbol provided outside the JIT.

For the JIT case it would probably have a value of 0, or whatever arbitrary value the JIT wants as it isn't actually necessary there.

For the JIT case it would probably have a value of 0, or whatever arbitrary value the JIT wants as it isn't actually necessary there.

Well, the TLS relocation resolves to an offset relative to the GOT, so the value GLOBAL_OFFSET_TABLE must match how these offsets were computed.   It's probably true you can choose any arbitrary value in the JIT, including zero, as long as it's used consistently.
However, this just reinforces my point that the JIT will resolve this, even if to always 0.   It will never be replaced by some other symbol, therefore having a replaceable name is not useful.

I've now updated the patch to include the KnownSymbol mechanism by @afonso360.  As discussed above, I've not included any "lookup" function to provide names from the outside for the well-known symbols.  Instead, they only have internal names for display/debug purposes (just like libcalls), and the well-known external name is hard-coded in the object backend.  (The JIT backend wouldn't need any symbol name, it can just implement the semantics directly.)
@bjorn3 does this look reasonable to you?

Hi @cfallin @bjorn3 @afonso360 as far as I can see, this version no longer has any open issues and should be good to go.  (It will conflict with https://github.com/bytecodealliance/wasmtime/pull/4546 as it pulls it parts of that change, but that should be easy to resolve once it's in.)   Is this now OK, or are there any further changes needed?

(It will conflict with https://github.com/bytecodealliance/wasmtime/pull/4546 as it pulls it parts of that change, but that should be easy to resolve once it's in.)

@uweigand it's not totally clear to me, do you mean you want to merge this PR first and then resolve the conflicts in #4546, or wait for #4546 then resolve conflicts here?

(It will conflict with #4546 as it pulls it parts of that change, but that should be easy to resolve once it's in.)

@uweigand it's not totally clear to me, do you mean you want to merge this PR first and then resolve the conflicts in #4546, or wait for #4546 then resolve conflicts here?

I think we should merge this PR first.  I copied the implementation of KnownSymbol initially from #4546, but then added a few changes to address issues that @bjorn3 had pointed out.  So the implementation here should be the correct one.


Fix error when parsing content schemas

Supersedes #752
We noticed quite a few Sentry entries when extracting content
for the content items that were republished via the PublishingAPI.
We found out that the payload for some schemas had an Array and
not an String which was unexpected because all our tests were green.
We had an issue in the way we were generating the samples, so this PR
fixes the underlying problem with the sample generation, and provide
a fix for the body with multiple document types
These were the hidden tests that we were not caching before
rspec './spec/integration/item/extract_content_all_schemas_spec.rb[1:1:14]' # Process parser with a list of content schemas extracts the content for: answer
rspec './spec/integration/item/extract_content_all_schemas_spec.rb[1:1:67]' # Process parser with a list of content schemas extracts the content for: licence
rspec './spec/integration/item/extract_content_all_schemas_spec.rb[1:1:62]' # Process parser with a list of content schemas extracts the content for: specialist_document
rspec './spec/integration/item/extract_content_all_schemas_spec.rb[1:1:43]' # Process parser with a list of content schemas extracts the content for: manual

Final review/pairing with @theKHutDeveloper


Connection management fixes

Updated CitadelDAO with some preemptive fixes. This should add some clarity to deadlocking issues when diagnosed.
Adressed issues:

https://github.com/CivMC/Citadel/issues/31
https://github.com/CivMC/Citadel/issues/30
https://github.com/CivMC/Citadel/issues/29
https://github.com/CivMC/Citadel/issues/28
https://github.com/CivMC/Citadel/issues/25
https://github.com/CivMC/Citadel/issues/24
https://github.com/CivMC/Citadel/issues/23
https://github.com/CivMC/Citadel/issues/35
https://github.com/CivMC/Citadel/issues/34
https://github.com/CivMC/Citadel/issues/33

Some of these are definitely my bad from lack of knowledge, more specifically the use of .autoCommit() however these fixes at the time massively overhauled the time taken to shutdown the server when CivClassics was taking 10+ mins per plugin to save out data on shutdown.
Thank you for the reviews and pull requests!

Test my changes thoroughly before putting them live. I'm a dumdum just like everybody else.
No shame in learning.


class_cloudflare.php file missing.

Hello,
I can't access the relevant file, any chance you can get it to me?
File : class_cloudflare.php

Looks like the original API project I was referencing is dead and buried.  It's outdated anyway.


BOM_RE doesnt cover all BOMs

The BOM_RE is only one of the many BOMs that are possible.  c.f. https://github.com/1441302031/luaGameFramework/blob/05a7a34a351c081efe76726d0f314a5e4bd4eefe/MyLuaGame/remove_bom.py

Actually it might, sorry.  I need to re-test.

Closing as this is a bit unclear.


consul-template 0.7.0 (new formula)

Generic template rendering and notifications with Consul

ping

This is open source; could you submit a PR to build this from source, please?

Closing, but would accept a formula to build from source in the main repo. Thanks!


Touchable event bug [Android]

...
Expect
Touchable events to be consistent between android & iOS.
Actual
Android doesn't render path correctly, when using Android
Reproduce
"react": "16.0.0",
"react-native": "0.50.3",
"react-native-svg": "5.5.1"

import React, { Component } from 'react'
import { View } from 'react-native'
import Svg, { Rect, Path } from 'react-native-svg'

export default class App extends Component<{}> {
  state = {
    isDown: false,
    path: ''
  }

  getCoords(e) {
    const { locationX, locationY } = e.nativeEvent
    const X = parseInt(locationX)
    const Y = parseInt(locationY)

    return `${X},${Y}`
  }

  down(e) {
    this.setState({
      path: `${this.state.path}M${this.getCoords(e)} `,
      isDown: true
    })
  }

  move(e) {
    if (this.state.isDown) {
      this.setState({
        path: `${this.state.path}L${this.getCoords(e)} `
      })
    }
  }

  up() {
    this.setState({
      isDown: false
    })
  }

  render() {
    return (
      <View style={{ flex: 1, width: '100%', height: '100%' }}>
        <View
          onStartShouldSetResponder={() => true}
          onMoveShouldSetResponder={() => true}
          onResponderGrant={this.down.bind(this)}
          onResponderMove={this.move.bind(this)}
          onResponderRelease={this.up.bind(this)}
          style={{ width: '100%', height: '50%', backgroundColor: '#eee' }}
        />
        <Svg style={{ width: '100%', height: '50%' }}>
          <Rect
            fill="#fff"
            width="100%"
            height="100%"
            onPressIn={this.down.bind(this)}
            onResponderMove={this.move.bind(this)}
            onPressOut={this.up.bind(this)}
          />
          <Path
            fill="none"
            stroke="#111"
            strokeWidth="2"
            d={this.state.path}
            strokeMiterLimit="5"
            strokeLinecap="round"
            strokeLinejoin="round"
            pointerEvents={() => 'none'}
          />
        </Svg>
      </View>
    )
  }
}

snack.expo.io
Run the example in IOS, drawing in the top grey area with cursor and note the svg path output in the white area, now try the same in the bottom white area. note (path rendered is consistent).
Now run the example in Android, note the white area path doesn't render properly, but works in the grey area indicating a bug in react-native-svg touchables.

Here is an ugly workaround: https://snack.expo.io/rJm7SuQyf
import React, { Component } from 'react';
import { View, Dimensions, Platform } from 'react-native';
import { Svg } from 'expo';

const android = Platform.OS === 'android';
const { width, height } = Dimensions.get('window');
const { Rect, Path } = Svg

export default class App extends Component {
  state = {
    isDown: false,
    path: ''
  }

  getCoords(e) {
    const { locationX, locationY } = e.nativeEvent
    const X = parseInt(locationX)
    const Y = parseInt(locationY)
    return [X, Y]
  }

  down(componentType, e) {
    let [ X, Y ] = this.getCoords(e);
    if (componentType === 'svg' && android) {
      Y -= height / 2;
    }
    this.setState({
      path: `${this.state.path}M${X},${Y}`,
      isDown: true
    })
  }

  move(e) {
    if (this.state.isDown) {
      const [ X, Y ] = this.getCoords(e);
      if (Y > (height/2)) return
      this.setState({
        path: `${this.state.path}L${X},${Y}`,
      })
    }
  }

  up() {
    this.setState({
      isDown: false
    })
  }

  render() {
    return (
      <View style={{ flex: 1, width: '100%', height: '100%' }}>
        <View
          onStartShouldSetResponder={() => true}
          onMoveShouldSetResponder={() => true}
          onResponderGrant={this.down.bind(this, 'native')}
          onResponderMove={this.move.bind(this)}
          onResponderRelease={this.up.bind(this)}
          style={{ width: '100%', height: '50%', backgroundColor: '#eee' }}
        />
        <Svg style={{ width: '100%', height: '50%' }}>
          <Rect
            fill="#fff"
            width="100%"
            height="100%"
            onPressIn={this.down.bind(this, 'svg')}
            onResponderMove={this.move.bind(this)}
            onPressOut={this.up.bind(this)}
          />
          <Path
            d={this.state.path}
            fill="none"
            stroke="#111"
            strokeWidth="2"
            strokeMiterLimit="5"
            strokeLinecap="round"
            strokeLinejoin="round"
            pointerEvents={() => 'none'}
          />
        </Svg>
      </View>
    );
  }
}

I suspect the event handler is called twice on android in svg elements, once with correct coordinates and once with coordinates relative to the root view. I subtracted the distance from the root in the down event handler and skipped any event larger than the intended svg viewport size in the move event handler.

@msand thanks for the quick response.
I ended up using the hack of tracking the  events as apposed to the SVG.Rect.
Your hack doesn't seem to work, if you remove the example , it now starts by drawing from the top.
https://snack.expo.io/B1I1LVV1M

Yes, you would then have to adapt the subtraction of the distance to the root in the down handler, i.e. removing this:
    if (componentType === 'svg' && android) {
      Y -= height / 2;
    }

As I said, it's an ugly hack, and merely a proof of concept which shows the underlying error.

 I've fixed some issues with the gesture responder logic and think this might be fixed as well.

Closing because of inactivity.


Update GCE load balancing guidance

Fixes #1602

This change is

http://cockroach-docs-review.s3-website-us-east-1.amazonaws.com/d8de06e9c3244c7d23cef83672c0e5f57f8e5085/

LGTM. Thanks for working through this, it should really help people.

http://cockroach-docs-review.s3-website-us-east-1.amazonaws.com/0a32839786ff7e97538d8d7679492daae716e789/

http://cockroach-docs-review.s3-website-us-east-1.amazonaws.com/f4c504967e3e866750c9dfe3439122adde0163e5/

http://cockroach-docs-review.s3-website-us-east-1.amazonaws.com/94427c03a80c546f97943b3ccaebd5042985680a/

http://cockroach-docs-review.s3-website-us-east-1.amazonaws.com/9df72c1a5155d7ec6e244cf8d90f8c12496290aa/


Is it possible to terminate long running process?

Hi,
I have a long running task in an external dll, which takes more than 30 secs to complete. We track the UI changes while the task is running and need to terminate the running task if the input values changed, and start the task again with the new values. Tried calling the DisposeAsync method but it seems to be not working as we needed. Is there a better way to achieve this using BlazorWorker? Thank you!
await backgroundService.DisposeAsync(); await worker.DisposeAsync();

worker.DisposeAsync() is supposed to abrubtly kill the worker. If that's not working there is probably a bug. Your use case is probably common so I'll write up an example in the demo project and I'll re-test it at the same time.
No point in disposing the service first, also that probably won't work as the notion of service is inside the process, which is single threaded, and thus can't head the call if it's busy running your code.

Thank you Tewr!

worker.DisposeAsync() works just fine.
However implementation of cancellation without killing the worker turned out trickier than I thought. Can't just write classic .net code as we are single-threaded.
The synchronisation context behaviour in mono-wasm is not working as I expected.
In any case I found there are some missing pieces in the library here, like service methods with async signature. Perhaps built-in support for cancellation token. It's an interesting use case, that's for sure.

You are right Tewr, worker.DisposeAsync() works fine. I was disposing the service first, which was giving errors.
Yes, killing the running worker seems to be challenging. We have decided to wait till the process is complete and re-run the task with new inputs. Please advice if you can think of a better way to achieve our needs. Thanks again!

I've managed to get this to work, but gets it's messy as #16 has not been implemented. You have to yield at some point so that the context gets the chance to read an incoming message which sets a flag somewhere that you can read to cancel the operation. Yielding has a hefty performance penality, so you can't yield in every loop, you have to find some delta that works for you. Works with await Task.Delay(100), Task.Delay(1) does not seem to work, this is what confused me at first. Not sure where the magic limit is yet.

Ok will try it. Thank you!

I've published the example here, also lots of changes in service.
This example shows that its feasable in the current state of things, but messy with a lot of bloat. The whole CancellationToken might be a tad overkill, but like a natural follow-up on supporting Tasks, I think they should probably be supported by the library as well.
Finally, Task.Delay(1) works fine for yielding. I must have done something else wrong yesterday.

Will try this, thank you Tewr!


[NP-3412] update help text ui

address: https://nanopay.atlassian.net/browse/NP-3412

Fix padding so scrollbar doesn't extend all the way to top and bottom and so that top and bottom padding are the same on initial screen.


[BUG] AD Migration | Connection to LDAP lost during un-migration and users skipped and given empty DNs | cannot login

Rancher Server Setup

Rancher version: v2.7.4 -> v2.7.5 -> v2.7.6-head
Installation option (Docker install/Helm Chart): Docker

Information about the Cluster

Kubernetes version: v1.26.4+k3s1

User Information

What is the role of the user logged in? (Admin/Cluster Owner/Cluster Member/Project Owner/Project Member/Custom): Admin

Describe the bug
For users that were on v2.7.4 and run into the AD auth issues on 2.7.5 (duplicate users and lost permissions), if the connection to the AD server is lost during the migration, some users appear to be skipped and their DNs are empty, while some users are successfully un-migrated. The users that were successfully un-migrated can login and everything looks dandy, but users that were skipped cannot login.
I checked the debug logs for this at two separate times

Within 1min of the docker container starting with the upgrade and it showed the LDAP connection errors
After the upgrade was complete and Rancher was available and it looked like the migration script was able to connect and migrate users

Error from the first log: WARNING] [migrate-ad-user] LDAP connection failed: 'Error creating connection: LDAP Result Code 200 "Network Error": dial tcp <AD_SERVER_IP>: i/o timeout', retrying...
I also noticed this line from the log: [DEBUG] [identify-ad-users] user <redacted> is GUID-based (<redacted>) and the Active Directory server knows it by the Distinguished Name ''
I have the full log saved as a txt file for the second check, so if dev would like to see that just ping me and I'll DM it.
To Reproduce

deploy 2.7.4
Enable AD Auth
Provision downstream rke2
Add a single user as with CRTB to the rke2 cluster
Login to Rancher with that user
Delete that user from AD
Add several more users for CRTBs and PRTBs
Login as each of those users
Upgrade to 2.7.5
Login as each of the users again
Upgrade to 2.7.6-head
Immediately try to block the AD server from connecting (I used docker exec -it <containerID> /bin/bash iptables -A OUTPUT -d  <AD_SERVER_IP> -j DROP
Check the logs, see the failed to connect errors
Rancher is up, check the state of the configmap, see it says 100% finished
Look at users and see dupes and empty DNs
Check docker logs again, see that it says users were migrated

Result
Users are seemingly skipped and given blank DNs when "migrated" and then cannot login
Expected Result
Users are either skipped and left with GUID or are un-migrated back to their DN
Screenshots
Not sure how to properly redact these screenshots and still provide useful information, so again if dev wants to see some screenshots just let me know and I can DM them.

PR: https://github.com/rancher/rancher/pull/42479

✅ PASS
Validation Environment

Component
Version / Type

Rancher version
Start 2.7.4 >>> 2.7.5 >>> v2.7.6-53ebd8cbbcf50528774023f08202b082f95d1937-head

Installation option
Docker

Cert Details
--acme-domain

Docker version
20.10.7, build f0df350

Downstream cluster type
Linode RKE2

Downstream K8s version
v1.25.12+rke2r1

Authentication providers enabled
AD

Logged in user role
AD admin, AD standard usser, local admin

Browser type
Opera GX

Browser version
LVL5 (core: 100.0.4815.82) (x86_64)

:muscle: Test Cases

#
Priority
Description & Link
PASS/FAIL

1
P0
Test 1
✅ PASS

:mag_right: #1 / Status: ✅ PASS
:small_red_triangle: Back to top

Test 1 details... Click to expand
Test Steps for Validation
Test Steps for Validation

Deploy Rancher version 2.7.4.
Activate AD authentication.
As an AD auth standard user, provision a downstream rke2 cluster.
Incorporate 6 AD users to the downstream cluster: 3 as owners, 3 as members.
Initiate login for all added users.
Remove 2 cluster owners from AD.
Upgrade to Rancher version 2.7.5.
Attempt user logins again, noting the absence of the cluster.
Transition to version 2.7.6-head.
Promptly obstruct the AD server's connection (utilizing the command: docker exec -it <containerID> /bin/bash iptables -A OUTPUT -d  <AD_SERVER_IP> -j DROP).
Adjust the log level to 'debug'.
Examine the system logs and the configuration map.

2023/08/22 06:12:35 [ERROR] [migrate-ad-user] unable to migrate user 'u-<redacted>' due to a connection failure; this user will be skipped
2023/08/22 06:12:35 [ERROR] [migrate-ad-user] unable to migrate user 'u-<redacted>' due to a connection failure; this user will be skipped

ConfigMap
apiVersion: v1
data:
  ad-guid-migration-status: FinishedWithSkipped
  skippedUsers: u-<redacted>,u-<redacted>,u-<redacted>,u-<redacted>,u-<redacted>,u-<redacted>
  skippedUsersCount: "6"
  statusLastUpdated: "2023-08-22T06:12:35Z"
kind: ConfigMap
metadata:
  creationTimestamp: "2023-08-22T06:12:29Z"
  labels:
    cattle.io/creator: norman
  name: ad-guid-migration
  namespace: cattle-system
  resourceVersion: "144695"
  uid: <redacted>

✅ Expected Outcome
Users are bypassed once the connection to AD is severed.
✅ Actual Outcome
Users are bypassed once the connection to AD is severed.