Add API for packet vectorized / async processing

Our goal is to use alternative ciphers for performance improvements, and the next step will be to support Async jobs with openssl 3.0.0.
We are making progress on the quicly integration in VPP (https://github.com/FDio/vpp/tree/master/src/plugins/quic), it works as it but we began to modify the code in order to optimize performances by batching cipher operations
For now we are able to use our own cipher engine by modifying quicly and picotls code (replacing ptls_aead_encrypt() / decrypt() and ptls_cipher_encrypt() / decrypt() functions ptr).
Currently we are trying to modify quicly to push a cipher operation for each packet and then process all operations just before sending/receiving data.  This behaviour needs many modifications in quicly and we want to discuss about that.
We plan to invest time on this evolution and make a PR, but if you have some ideas or suggestions about that we’re open.

Thank you for using quicly in VPP.
I have always had adding support for crypto offload as one of the possibilities. Let's make that happen. FWIW, what I have had in my mind is something like this:

Create your own ptls_cipher_suite_t, that declares itself as doing AES128GCM (or the cipher you offload), but in fact is a no-op. [a]

This cipher suite will be registered to ptls_context_t that is referred from quicly_context_t.

Create a callback interface (like quicly_packet_allocator_t, quicly_cid_encryptor_t, ...) that does the packet encryption and decryption (calling it quicly_codec_t for now; I do not have a strong opinion about the name). [q]

Current code (i.e. software codec) would be called like quicly_default_codec_t, and the implementation would be moved to lib/defaults.c.
You might want to look into how quicly_cid_encryptor_t and st_quicly_default_encrypt_cid_t are defined and used. It resembles the design pattern I am talking here.

Add a void pointer to quicly_datagram_t that can be used to carry arbitrary data [q]

This would be used to pass values from your no-op cipher to the crypto offload engine.

Depending on the need, also add flag(s) to quicly_decoded_packet_t for the decode side. [q]

The bullet points marked [q] are the changes that would happen in quicly. Those marked [a] are the things that would happen on the application (e.g., VPP) side.
All that said, I am open to discussing any other approaches. Please let me know what you think.

Thanks a lot for your response.
The first point is ok for us (create our own ptls_cipher_suite_t and register it in ptls_context_t/quicly_context_t), this was already done in vpp quic plugin and works well with our internal crypto engines.
For the other things we need to try this and see if your design can works with our needs.
We will come back to you soon to discuss about that.


✨ Add DATA_OFFSET for compatibility with solmate

Description
Describe the changes made in your pull request here.
Add the DATA_OFFSET constant to the library so it can be a drop-in replacement of solmate's SSTORE2
Checklist
Ensure you completed all of the steps below before submitting your pull request:

[ ] Ran forge fmt?
[ ] Ran forge snapshot?
[ ] Ran forge test?

Pull requests with an incomplete checklist will be thrown out.

This is intentional. The underlying data offset should be transparent to the user.

Nvm, i think we can add it, as it's a library and not an abstract class (no need to be concerned about namespace pollution).
Thanks!


Add object methods to attributeProxy

The common object methods like Object.keys() do not return useful information for the attributeProxy. Methods should be added to the proxy to replicate these methods so that they return the attribute information stored in the proxy.

Will be resolved in migrated code se https://github.com/Kurohyou/Roll20-Snippets/issues/31 for more details.


adding ios-xr support

Seems pretty straight forward, it's a wrapper around rpm things to do pkg management?

@jjasghar Not exactly...
Specinfra is the platform-specific stuff behind serverspec, which is used by the Cisco Cookbook for testing. We had trouble getting our Cisco-related changes accepted to the specinfra project I believe, so we maintain this fork.
These changes allow specinfra-cisco to detect an IOS-XR switch correctly so it can run tests. IOS-XR is based on Wind River Linux, which is close enough to a Red Hat system such that we subclass off of that.
Similar changes were done during the initial release of specinfra-cisco to support Nexus. This is doing the same thing, but for XR.

Ah ok, i think i get it now. From what i see this looks good.


bluetooth: conn: add conn to recycled callback

Add the connection object that was recycled to the recycled callback. This can be used to match the connections created from advertising sets to the recycled callback invocation.
In turn, this allows software libraries to manage only a single advertising set, restarting the set when a connection created from that set terminates, emulating the behaviour of !BT_LE_ADV_OPT_ONE_TIME for extended advertising.

The other option is to introduce some form of BT_LE_ADV_OPT_RESTART flag that triggers the advertising to restart, although I'm assuming there is some reason the following was done:
https://github.com/zephyrproject-rtos/zephyr/blob/494f88070f6bb909389630264e4f89c71072ae53/include/zephyr/bluetooth/bluetooth.h#L543-L547

There are two competing suggestions here for the "handle" that is provided back to the user. The first is bt_conn_id(conn) from @alwa-nordic, the second is to return const struct conn* from @Thalley.
It's obviously a bit difficult to do both, is there any agreement on which is preferred?

There are two competing suggestions here for the "handle" that is provided back to the user. The first is bt_conn_id(conn) from @alwa-nordic, the second is to return const struct conn* from @Thalley.
It's obviously a bit difficult to do both, is there any agreement on which is preferred?

I feel like we need to take a step back and find some third solution. We've failed somewhere along the way in our API design, if to accomplish a valid use case the application needs to hold on to a bt_conn pointer which it doesn't own a reference to. What's being proposed also seems inherently racy, since there's no guarantee that the same connection object can be reused for the same advertising instance.

There are two competing suggestions here for the "handle" that is provided back to the user. The first is bt_conn_id(conn) from @alwa-nordic, the second is to return const struct conn* from @Thalley.
It's obviously a bit difficult to do both, is there any agreement on which is preferred?

I feel like we need to take a step back and find some third solution. We've failed somewhere along the way in our API design, if to accomplish a valid use case the application needs to hold on to a bt_conn pointer which it doesn't own a reference to. What's being proposed also seems inherently racy, since there's no guarantee that the same connection object can be reused for the same advertising instance.

That's fair, and comes under the alternate option I mentioned around BT_LE_ADV_OPT_ONE_TIME . Do you have any comments on that?

@JordanYates can you share the application that requires this? Or maybe make a minimum example to illustrate the need?

@JordanYates can you share the application that requires this? Or maybe make a minimum example to illustrate the need?

I have explained the use case here.
I'm surprised this hasn't come up before. In a multi-advertiser application, what is the intended logic for resuming advertising sets as connections terminate? To me, resuming the set that triggered the connection in the first place is the obvious desired behaviour.

@JordanYates can you share the application that requires this? Or maybe make a minimum example to illustrate the need?

I have explained the use case here. I'm surprised this hasn't come up before. In a multi-advertiser application, what is the intended logic for resuming advertising sets as connections terminate? To me, resuming the set that triggered the connection in the first place is the obvious desired behaviour.

Thanks. Re-reading it I think I understand it a bit better now.
What I unfortunately still fail to understand is why you need to use the recycled callback at all. Why not just the disconnected callback to determine whether to restart legacy advertising (for iOS) again?

@JordanYates can you share the application that requires this? Or maybe make a minimum example to illustrate the need?

I have explained the use case here. I'm surprised this hasn't come up before. In a multi-advertiser application, what is the intended logic for resuming advertising sets as connections terminate? To me, resuming the set that triggered the connection in the first place is the obvious desired behaviour.

Thanks. Re-reading it I think I understand it a bit better now. What I unfortunately still fail to understand is why you need to use the recycled callback at all. Why not just the disconnected callback to determine whether to restart legacy advertising (for iOS) again?

Because of the exact reason that recycled was added in the first place. The connection object is still valid in the disconnected callback (and can remain so for an arbitrary period of time due to bt_conn_ref), so attempting to resume connectable advertising there will fail due to insufficient connection objects (if BT_MAX_CONN == BT_EXT_ADV_MAX_ADV_SET)

Thanks. Re-reading it I think I understand it a bit better now. What I unfortunately still fail to understand is why you need to use the recycled callback at all. Why not just the disconnected callback to determine whether to restart legacy advertising (for iOS) again?

Because of the exact reason that recycled was added in the first place. The connection object is still valid in the disconnected callback (and can remain so for an arbitrary period of time due to bt_conn_ref), so attempting to resume connectable advertising there will fail due to insufficient connection objects (if BT_MAX_CONN == BT_EXT_ADV_MAX_ADV_SET)

But isn't that why our documentation recommends using a k_work_submit for that reason?
The recycled documentation also state that there is no guarantee that an object be allocated anyhow (https://docs.zephyrproject.org/latest/doxygen/html/structbt__conn__cb.html#a1bd8d99988ad0ae3f79aad3d03fcbd8b), so arguably your chances of restarting connectable (legacy) advertising in the disconnected callback is comparable to the recycled callback.
It feels like I'm missing some crucial part to fully understand why recycled is required for this usecase

Thanks. Re-reading it I think I understand it a bit better now. What I unfortunately still fail to understand is why you need to use the recycled callback at all. Why not just the disconnected callback to determine whether to restart legacy advertising (for iOS) again?

Because of the exact reason that recycled was added in the first place. The connection object is still valid in the disconnected callback (and can remain so for an arbitrary period of time due to bt_conn_ref), so attempting to resume connectable advertising there will fail due to insufficient connection objects (if BT_MAX_CONN == BT_EXT_ADV_MAX_ADV_SET)

But isn't that why our documentation recommends using a k_work_submit for that reason?
The recycled documentation also state that there is no guarantee that an object be allocated anyhow (https://docs.zephyrproject.org/latest/doxygen/html/structbt__conn__cb.html#a1bd8d99988ad0ae3f79aad3d03fcbd8b), so arguably your chances of restarting connectable (legacy) advertising in the disconnected callback is comparable to the recycled callback.
It feels like I'm missing some crucial part to fully understand why recycled is required for this usecase

Because the same documentation you linked says that this is the way to do it:

Use this to e.g. re-start connectable advertising or scanning.

There are no guarantees only because other actors in the system might be greedy. If you are writing all the actors, recycled is guaranteed to work, even if some libraries hold the connection object for a period after the disconnected callback.
The problem with k_work_submit is what do you do if restarting the advertising fails because of insufficient connections? You have to try again later, which means you are using k_work_delayable instead of k_work, and setting up some periodic retry. All of which is more complicated than just using recycled, which is created for this purpose.

There are no guarantees only because other actors in the system might be greedy. If you are writing all the actors, recycled is guaranteed to work, even if some libraries hold the connection object for a period after the disconnected callback.

Not sure I follow this.
As per the documentation, recycled does not give an guarantees if there are multiple actors. If you control all actors, as I think you are writing, then wouldn't the same guarantee exist for the disconnected callback?
So either you control all actors and you can ensure that it will work, or you don't control all actors and you can't ensure anything regardless of which callback you are using.
I do get your point that there is possibly a better chance of a k_work_submit working in recycled than in disconnected, but as far as I can tell, you cannot ensure anything in recycled that you cannot ensure in disconnected (which is nothing if there are multiple actors).

With the current API as we have it, wouldn't this work for your use-case?
Similar to: https://github.com/zephyrproject-rtos/zephyr/pull/77775#discussion_r1738033728
static const struct bt_le_ext_adv_cb adv_cb = {
	.connected = adv_set_connected,
};
static struct bt_conn *legacy_conn;

BT_CONN_CB_DEFINE(conn_cb) = {
	.recycled = conn_recycled_cb,
	.disconnected = disconnected,
};

static void adv_set_connected(struct bt_le_ext_adv *adv, struct bt_le_ext_adv_connected_info *info)
{
	legacy_conn  = bt_conn_ref(info->conn);
}

static void disconnected(struct bt_conn *conn, uint8_t reason)
{
	if (conn == legacy_conn) {
		bt_conn_unref(conn);
		legacy_conn = NULL;
	}
}

static void conn_recycled_cb(void)
{
	if (legacy_conn) {
		return;
	}
	// Schedule work to restart advertising
	k_work_schedule(&restart_advertising, K_NO_WAIT);
}

With the current API as we have it, wouldn't this work for your use-case?
Similar to: https://github.com/zephyrproject-rtos/zephyr/pull/77775#discussion_r1738033728

This logic immediately falls over if the "other" advertising sets is connectable and it terminates or is stopped. There is no legacy connection, so it will try to restart the legacy set every time.
Even if that wasn't the case, the proposal is inherently racy in the context of two connections terminating at once.

I feel like we need to take a step back and find some third solution. We've failed somewhere along the way in our API design, if to accomplish a valid use case the application needs to hold on to a bt_conn pointer which it doesn't own a reference to.

Proposal for API: For this use case, optimally the application would manage bt_conn slots explicitly with "bt_conn_alloc()" and pass that to "bt_adv_start_conn()". After disconnection, and once the connection object is "dead", the application can reuse the connection slot by passing it to "bt_adv_start_conn()" again without having to allocate again.
I think this would be a major redesign. I'm not sure we could do it without a lot of breakage.

After disconnection, and once the connection object is "dead", the application can reuse the connection slot by passing it to "bt_adv_start_conn()" again without having to allocate again.

How would the application know that the connection is dead? We already know that disconnected is insufficient, and there is no parameter in the recycled callback.

There are two competing suggestions here for the "handle" that is provided back to the user. The first is bt_conn_id(conn) from @alwa-nordic, the second is to return const struct conn* from @Thalley.
It's obviously a bit difficult to do both, is there any agreement on which is preferred?

I feel like we need to take a step back and find some third solution. We've failed somewhere along the way in our API design, if to accomplish a valid use case the application needs to hold on to a bt_conn pointer which it doesn't own a reference to. What's being proposed also seems inherently racy, since there's no guarantee that the same connection object can be reused for the same advertising instance.

What OP does is safe. But the reasoning is complicated, which is not great API design.
It's safe because the conn pointer is used here as a handle to a connection slot (bt_conn_id), not to a connection object. Unlike connection objects, connection slots are static, so their handle is forever. bt_le_ext_adv_cb.connected stores the slot handle, and the recycled() handler compares the slot handle. The recycled() handler does not (semantically) address any connection objects. It's code smell that there is a dangling legacy_conn pointer, but that is fixed by either making it a void pointer (documented as referring to a slot) or just a slot number.
We just have to be careful to not delude our users into thinking they are getting a connection object reference in recycled(). My opinion is that giving the slot number, from bt_conn_id, is fine, and "weird enough" API that uses will think twice before treating it as a connection object reference.
I absolutely think we should not give a bt_conn * as an argument to recycled(). There is an implicit understanding that a bt_conn * argument either moves or borrows a reference. We must not muddy this. Dangling pointers are a bad idea, always.

There are two competing suggestions here for the "handle" that is provided back to the user. The first is bt_conn_id(conn) from @alwa-nordic, the second is to return const struct conn* from @Thalley.
It's obviously a bit difficult to do both, is there any agreement on which is preferred?

I feel like we need to take a step back and find some third solution. We've failed somewhere along the way in our API design, if to accomplish a valid use case the application needs to hold on to a bt_conn pointer which it doesn't own a reference to. What's being proposed also seems inherently racy, since there's no guarantee that the same connection object can be reused for the same advertising instance.

What OP does is safe. But the reasoning is complicated, which is not great API design.
It's safe because the conn pointer is used here as a handle to a connection slot (bt_conn_id), not to a connection object. Unlike connection objects, connection slots are static, so their handle is forever. adv_set_connected() stores the slot handle, and the recycled() handler compares the slot handle. The recycled() handler does not (semantically) address any connection objects. It's code smell that there is a dangling legacy_conn pointer, but that is fixed by either making it a void pointer (documented as referring to a slot) or just a slot number.
We just have to be careful to not delude our users into thinking they are getting a connection object reference in recycled(). My opinion is that giving the slot number, from bt_conn_id, is fine, and "weird enough" API that uses will think twice before treating it as a connection object reference.
I absolutely think we should not give a bt_conn * as an argument to recycled(). There is an implicit understanding that a bt_conn * argument either moves or borrows a reference. We must not muddy this. Dangling pointers are a bad idea, always.

Using the index to identify a specific connection, rather than using the pointer, sounds like a good idea anyhow, and providing the index in the recycled callback should be harmless as the index can't really be used for anything but comparison, and bt_conn_lookup_index will return NULL if the reference counter is 0.

The talk about using the connection id/slot is not the worst of the options discussed so far, so I'm 100% opposed to it. That said, there are a few parts of the discussion that are unclear to me:

After disconnection, and once the connection object is "dead", the application can reuse the connection slot by passing it to "bt_adv_start_conn()" again without having to allocate again.

How would the application know that the connection is dead? We already know that disconnected is insufficient, and there is no parameter in the recycled callback.

If I understood correctly, the insufficiency comes from the fact that the object can't be re-allocated in the disconnected callback, since the stack still holds a reference at that point. However, if the application explicitly allocated the connection it doesn't need to free it, rather it can just hold on to the original reference without calling bt_conn_alloc() and pass it again to bt_adv_start_conn(), right?
What about adding a "disconnected" callback to the advertising set, as a counterpart to the existing "connected" callback? Would that help us here at all?

It's safe because the conn pointer is used here as a handle to a connection slot (bt_conn_id), not to a connection object. Unlike connection objects, connection slots are static, so their handle is forever. adv_set_connected() stores the slot handle, and the recycled() handler compares the slot handle. The recycled() handler does not (semantically) address any connection objects. It's code smell that there is a dangling legacy_conn pointer, but that is fixed by either making it a void pointer (documented as referring to a slot) or just a slot number.

@alwa-nordic I assume what you're describing is for how you envision it would be? At least I didn't find anything like the above in the existing code base. The main problem with all this is that it seems to assume that the stack somehow reserves a connection for a given set, even though in reality (at least right now) there's a chance that some other entity could re-allocate the freed connection object for some other purpose before the app has the chance to reuse it for its advertising set.

If I understood correctly, the insufficiency comes from the fact that the object can't be re-allocated in the disconnected callback, since the stack still holds a reference at that point.

Not the stack, any software library anywhere in the system.

What about adding a "disconnected" callback to the advertising set, as a counterpart to the existing "connected" callback? Would that help us here at all?

I think it would depend on the semantics. If it is called at the same time as bt_conn.disconnected, then no, because all the same limitations would apply. If it was called at the same time as bt_conn.recycled, then yes, it would work as a solution.

Your confusion is completely justified. Sorry, I mean't to say I'm not 100% opposed to it.

It really sounds to me like we'd want a way to persistently associate a struct bt_conn * with a struct bt_le_ext_adv, which means that once associated the bt_le_ext_adv struct persistently holds a reference to the connection, even over disconnected states. It'd be most naturally done in these two places, I think:
https://github.com/zephyrproject-rtos/zephyr/blob/8c32a82e47f5d1a2871ec99b0c8b61eb789f9fcb/subsys/bluetooth/host/adv.c#L1088-L1095
https://github.com/zephyrproject-rtos/zephyr/blob/8c32a82e47f5d1a2871ec99b0c8b61eb789f9fcb/subsys/bluetooth/host/adv.c#L1338-L1345
Instead of unrefing the object the code would simply attach it to the bt_le_ext_adv struct. When bt_le_ext_adv_start() is called again the code would first check if it has an already attached conn object (and that the state of this object is DISCONNECTED) and reuse that instead of attempting to allocate a new one.

@alwa-nordic I assume what you're describing is for how you envision it would be? At least I didn't find anything like the above in the existing code base.

I was referring to What OP does.

It really sounds to me like we'd want a way to persistently associate a struct bt_conn * with a struct bt_le_ext_adv

It's unnecessarily restrictive to tie this to advertisers. There is a just-as-valid use case for bt_conn_le_create.
I would prefer a way to persistently allocate a bt_conn. If we don't want to introduce a new type for connection slots, then we can have the bt_conn gain an "empty" state, which it defaults to on allocation, and must return to before de-allocation. So long as there are references, the object will not transition to the empty state, for backwards compatibility. We add a new "weaker" reference count that keeps the object alive, but will not prevent the object from entering the empty state. A disconnected object transitions to empty automatically (asynchronously). Entering the empty state generates an event.
For hygiene, the empty state should give useless results or errors for e.g. bt_conn_get_info. It becomes API that a disconnected bt_conn retains connection info.

BTW; A bit of-topic, but relevant for API discussion:
Not sure about all the pros and cons, but we could remove the requirement to allocate a connection object when starting a connectable advertiser. The connection can instead be rejected at create time if we are not able to allocate an object.
This enables the application to have multiple connectable advertisers that all stop when one receive a connection without allocating a connection object for each advertiser.
If we combine this with the an allocation API, we can add API trough which the application is asked to provide the connection object.

Not sure about all the pros and cons, but we could remove the requirement to allocate a connection object when starting a connectable advertiser. The connection can instead be rejected at create time if we are not able to allocate an object.

We used to have exactly that in the past. IIRC the justification for pre-allocation was to be able to guarantee a successful connection and to be able give an early error to the app. Another way it was justified to allocate up front was that connectable advertising can be seen as an early state of an actual connection. I failed to find to the PR that changed the policy on this, but along the way I ran into some interesting and mildly related bits from the past, like #16874.

If we combine this with the an allocation API, we can add API trough which the application is asked to provide the connection object.

A connection allocation API sounds like a useful feature to me, especially when complemented with other APIs that can take the object as input.

3. App owned, app allocated (similar to how the L2CAP/GATT APIs are)
Each have their pro's and con(n)s, but I'm not objecting to modify our API to support more use cases, but I would be vary of supporting too many ways of allocating connections.

The one thing we'd loose with app owned, is bt_conn_index(). That API is used to do 1:1 mappings from a connection object to protocol/profile specific data, however it's entirely built on the assumption that there's a single place which defines the set of allocatable connection objects.

Another way it was justified to allocate up front was that connectable advertising can be seen as an early state of an actual connection.

I have some suspicion automatic resume was modeled after a Unix TCP listening socket. That does not fit into this picture. OTOH, now that we are getting rid of that, advertising as an early state of connection makes more sense.

The one thing we'd loose with app owned, is bt_conn_index(). That API is used to do 1:1 mappings from a connection object to protocol/profile specific data, however it's entirely built on the assumption that there's a single place which defines the set of allocatable connection objects.

Losing that would be a big problem, as it is the only way (AFAIK) to allocate arbitrary state against a connection without needing malloc.
struct my_software_state states[CONFIG_BT_MAX_CONN];

void bt_conn_callback(struct bt_conn *conn, ...) {
   struct my_software_state *state = states[bt_conn_index(conn)];
   ...
}

The one thing we'd loose with app owned, is bt_conn_index(). That API is used to do 1:1 mappings from a connection object to protocol/profile specific data, however it's entirely built on the assumption that there's a single place which defines the set of allocatable connection objects.

Losing that would be a big problem, as it is the only way (AFAIK) to allocate arbitrary state against a connection without needing malloc.
struct my_software_state states[CONFIG_BT_MAX_CONN];

void bt_conn_callback(struct bt_conn *conn, ...) {
   struct my_software_state *state = states[bt_conn_index(conn)];
   ...
}

While not useful as a index, there's also the handle that is unique for such lookups (once the connection is established).
That being said, there's nothing preventing us from having app-allocated and stack-controlled information, and such an index could be controlled and set by the stack assuming there's some sort of register function similar to bt_gatt_service_register

Bluetooth WG:

The problem is that providing conn to the recycled callback means passing a pointer that is no longer valid (the connection obj has been put back into the pool)

Suggestion to handle the use case (@JordanYates):

Start legacy adv set
Start ext adv set
Get connected callback from the legacy adv set, take a reference to the conn
Get disconnected callback from the connection from point 3., set a flag legacy_adv_should_run and give conn reference back
For every recycled callback you get, schedule a restart_advertiser work item, and in that work item, if the legacy_adv_should_run if set, try to restart the legacy adv and, if it succeeds, clear the legacy_adv_should_run


Support for custom JSON serializer

It was needed in my project to automatically serialize datetime in RPC replies. Maybe you'll find it useful too.

DjangoJSONEncoder converts datetime objects to a fixed format "%Y-%m-%d %H:%M:%S", which sometimes is not what's required. For dates, ISO 8601 is commonly used, but it's incompatible with the format above. So I think there is sense in having a custom serializer.

I can see the sense in a custom serializer. However, why not make the setting allow you to set a custom encoder object. This way we could set the default to DjangoJSONEncoder or something else sensible. That seems useful so that datetimes can be handled out of the box. That seems more useful than having to create a one off function. Thoughts?

Yes, I agree, that would be better. I'll implement it in my branch in a day or so.

I've finally replaced function with class. Default serializer is DjangoJSONEncoder.

Merged!


Bump junit version again to fix the security vulerability

What changes are proposed in this pull request?
fix https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-15250
see GHSA-269g-pwp5-87pp
Why are the changes needed?
Please clarify why the changes are needed. For instance,
The JUnit4 test rule TemporaryFolder contains a local information disclosure vulnerability.
Does this PR introduce any user facing changes?
Please list the user-facing changes introduced by your change, including
no

alluxio-bot, merge this please.

Apologies for the revert in #15720, this PR is just re-adding the version bump.

Thank you @ZhuTopher for looking into this!

Why does the production code depends on junit which should only be used for tests? Why not move this dependency to tests scope?

That's a good point @kokosing, I'm not sure if we use junit elsewhere but I'd imagine not. If there isn't an issue already for that you're welcome to submit that, thanks!

Why does the production code depends on junit which should only be used for tests? Why not move this dependency to tests scope?

Hello @kokosing , I had the same feeling when I saw the security vulnerability report.   But according the the pom I found the junit actually in the test scope.   I guess the security scanner might ignore the scope.


Benchmarks overhaul

Simplified the representation of benchmarks, targets, and queries
Upgraded the query runner (now in request.py) to enable multiple concurrent requests and (optionally) separate fetching and scoring
Added a request to Node Normalization during evaluation to fairly consider all equivalent CURIEs
Implemented information retrieval metrics Precision @ k, Recall @ k, mAP @ k, mean reciprocal rank, and top-k accuracy
Added a result object to handle plotting metrics and dumping them to JSON
Added command-line interface for fetching, scoring, and evaluating results (defined in setup.py)
Updated READMEs and requirements.txt

@cbizon @kennethmorton


included header file

Description of Change

Checklist

[x] Added description of change
[x] Added file name matches File name guidelines
[x] Added tests and example, test must pass
[x] Added documentation so that the program is self-explanatory and educational - Doxygen guidelines
[x] Relevant documentation/comments is changed or added
[x] PR title follows semantic commit guidelines
[x] Search previous suggestions before making a new one, as yours may be a duplicate.
[x] I acknowledge that all my contributions will be made under the project's license.

Notes:

this issue is a user side issue and implemented in the compiler

ok thankyou


fea: use npx@

This is a more correct version of: https://github.com/bgd-labs/aave-helpers/pull/128

--yes is needed as otherwise on most systems, a prompt would be shown, which foundry cannot handle.
-s is needed as otherwise npm logs install data, which again foundry cannot handle.

Please note though that this has some drawbacks due to the nature of how forge and npx work.
Forge tries to run test concurrently, which means it will run npx concurrently.
npx on the other hand isn't quite good at handling concurrency on install so in some test env i managed to break the npx installation with concurrent writes to node modules.
When @bgd-labs/aave-cli is already installed to the project though, non of this matters as npx will take the pre-installed version.


WIP do not merge

Just want to see if Travis can build this.

Closing this now that I have something to fix.


[Bug]: Empty Text Response Bug in Chat View

What version are you using?
I'm using FlutterGPT: AI Copilot with Gemini inside Dart v0.2.0
What happened?
When using the chat view in the FlutterGPT VSCode extension, I observed a bug where it responds even when the user enters empty text (whitespace) and presses Enter. This behavior is unexpected, and I believe it would be better to prompt the user to enter something meaningful before pressing Enter when the user doesn't type anything and presses Enter.
Expected Behavior
I expect that it should not respond when the user enters empty text, and instead, a prompt or notification (e.g., snack bar) should be displayed, indicating that the user needs to type something before pressing Enter.
Steps to reproduce
1. Open the chat view in the FlutterGPT extension.
2. Enter whitespace or leave the text input empty.
3. Press Enter.

Supporting info to reproduce
I'm attaching an image depicting the above-described behavior

Relevant log output
No response

Hello @yatendra2001 👋
I want to work on this issue, so please consider assigning it to me.

hey @superiorsd10 , thanks for opening this bug. Assigned to you.

Hello @yatendra2001 👋
Thanks for assigning this issue to me. I have submitted a PR for your review.
Thank you,

closing this issue, resolved by PR #144


[TOOLS] Default upgrades_from to an empty string.

When this script is run from make-stub-permanent the ENV variable is an empty string. When it's run from release-framework-to-universe the ENV variable isn't set, so os.environ.get('UPGRADES_FROM') returns None.

Thanks @samvantran.
The issue was introduced with https://github.com/mesosphere/dcos-commons/pull/2583


Analytics service is now refactored

In the refactoring process of the service, the first step was to walk through the code of the service and try to type it so to get some understanding on what's going on there. Then, we would create a bunch of tests to obtain current resulting states and afterwards use them to match answers from the refactored version. At last, the service itself was written in "pythonic" way, i.e. using list/dict comprehensions, standard functions, and trying not to repeat ourselves.
Only two files are relevant:

app/api/analytics/service.py
test/unit/test_analytics_service.py

Hello @IIaKyJIuH! Thanks for opening this PR. We checked the lines you've touched for PEP 8 issues, and found:

In the file app/api/analytics/service.py:

Line 141:51: E231 missing whitespace after ':'
Line 141:53: E251 unexpected spaces around keyword / parameter equals
Line 168:24: E231 missing whitespace after ':'
Line 168:26: E251 unexpected spaces around keyword / parameter equals

In the file main.py:

Line 28:1: W391 blank line at end of file

Пара лишних файлов из фронтенда прилипли.

Пара лишних файлов из фронтенда прилипли.

Убрал лишние файлы из фронтенда


Support for -Version 2 option

Support for the "-Version 2" parameter
Hello, I hope that I'm right here.
I wrote a powershell script in Version 2 for controlling the CAD system Catia v5.
I updated to Powershell 5 and the script didn't work anymore.
It's still okay, if I use the "-Version 2" parameter.
How long is this option supported?
Thank you for your help.
Kind regards
Kevin

Not related to PowerShell core.  To answer your question, this is supported so fat till 2019, its possible where ever version 2.0 is enabled and -version is an option available for powershell.exe which is already don with the development, hence this option will be there till powershell.exe dies :-)

Yeah, this isn't available to PowerShell core, and isn't even guaranteed in any version of windows PowerShell.
Many security-conscious folks widely uninstall PowerShell V2 from every machine it's still available on, which breaks this option.
I would recommend simply updating your script. :slightly_smiling_face:

Thank you both for your help.
@vexx32 the problem appears in the following lines:
$catia=new-object -com catia.application
$catia.documents.open($CatiaFile)
Powershell seems to have problems finding the 'open'-routine:
You cannot call a method on a null-valued expression.
At line:1 char:1
+ $catia.documents.open("C:\temp\test.CATPart")
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidOperation: (:) [], RuntimeException
    + FullyQualifiedErrorId : InvokeMethodOnNull

Opening documents in Office works this way, so I guess that Catia is the problem...

Mmm you'll need to look back a bit farther. It can't find the method, because the .documents property is empty. Might want to check the contents of $catia and check the properties it has available, as that might have differences in the way the COM object manifests between versions of PowerShell. 🙂

@inno-kd Try powershell -mta instead.  PowerShell 2's default runspace has an apartment state of MTA , later versions moved to STA since that's compatible with more things.

Mmm you'll need to look back a bit farther. It can't find the method, because the .documents property is empty. Might want to check the contents of $catia and check the properties it has available, as that might have differences in the way the COM object manifests between versions of PowerShell.

@vexx32 Thank you for the hint. This is the content list of $catia:
$catia=new-object -com catia.application
$catia | gm

   TypeName: System.__ComObject#{7d2c8116-dc44-0000-0280-030ba6000000}

Name                          MemberType Definition
----                          ---------- ----------
BeginURConcatenation          Method     void BeginURConcatenation ()
CreateMail                    Method     Mail CreateMail ()
CreateSendTo                  Method     SendToService CreateSendTo ()
DisableNewUndoRedoTransaction Method     void DisableNewUndoRedoTransaction ()
EnableNewUndoRedoTransaction  Method     void EnableNewUndoRedoTransaction ()
FileSelectionBox              Method     string FileSelectionBox (string, string, CatFileSelectionMode)
GetItem                       Method     CATBaseDispatch GetItem (string)
GetWorkbenchId                Method     string GetWorkbenchId ()
Help                          Method     void Help (string)
InputBox                      Method     string InputBox (string, string, string, short, short, string, int)
MsgBox                        Method     short MsgBox (string, short, string, string, int)
Quit                          Method     void Quit ()
StartCommand                  Method     void StartCommand (string)
StartWorkbench                Method     void StartWorkbench (string)
StopURConcatenation           Method     void StopURConcatenation (string)
ActiveDocument                Property   Document ActiveDocument () {get}
ActivePrinter                 Property   Printer ActivePrinter () {get} {set}
ActiveWindow                  Property   Window ActiveWindow () {get}
Application                   Property   Application Application () {get}
Batch                         Property   Batch Batch () {get} {set}
CacheSize                     Property   int CacheSize () {get} {set}
Caption                       Property   string Caption () {get} {set}
DisplayFileAlerts             Property   bool DisplayFileAlerts () {get} {set}
Documents                     Property   Documents Documents () {get}
FileSearchOrder               Property   string FileSearchOrder () {get} {set}
FileSystem                    Property   FileSystem FileSystem () {get}
FullName                      Property   string FullName () {get}
Height                        Property   float Height () {get} {set}
HSOSynchronized               Property   bool HSOSynchronized () {get} {set}
Interactive                   Property   bool Interactive () {get} {set}
Left                          Property   float Left () {get} {set}
LocalCache                    Property   string LocalCache () {get} {set}
Name                          Property   string Name () {get} {set}
Parent                        Property   CATBaseDispatch Parent () {get}
Path                          Property   string Path () {get}
Printers                      Property   Printers Printers () {get}
RefreshDisplay                Property   bool RefreshDisplay () {get} {set}
SettingControllers            Property   SettingControllers SettingControllers () {get}
Settings                      Property   Settings Settings () {get}
StatusBar                     Property   string StatusBar () {get} {set}
SystemConfiguration           Property   SystemConfiguration SystemConfiguration () {get}
SystemService                 Property   SystemService SystemService () {get}
Top                           Property   float Top () {get} {set}
UndoRedoLock                  Property   bool UndoRedoLock () {get} {set}
Visible                       Property   bool Visible () {get} {set}
Width                         Property   float Width () {get} {set}
Windows                       Property   Windows Windows () {get}

@SeeminglyScience Thank you, too. I tried to start PS with the -mta parameter but it didnt work either.
Is there any other way to create the com-Object?

It might be a casing issue, then? Your original code is looking at $catia.documents, and the property here is listed with capital D not lowercase. In most cases it won't make a difference, but this may be one of the times it does. :slightly_smiling_face:


[NPM-3302] Add retries for connection query

What does this PR do?
Attempt at fix for https://datadoghq.atlassian.net/browse/NPM-3302?focusedCommentId=1625932
Motivation

Additional Notes

Possible Drawbacks / Trade-offs

Describe how to test/QA your changes

/merge


End-to-End tutorial link is broke

I am trying to run the through tutorial in order to understand the Parsing process, but 'End-to-end' tutorial supplied in 'Intro_Data_model.ipynb' is not working

The link assumes you have the repository cloned and are viewing the tutorial in jupyter notebook.
That is, the link is to ../hardware/max_storage_temp_tutorial.ipynb.
You can view the notebook on GitHub here: https://github.com/HazyResearch/fonduer-tutorials/blob/master/hardware/max_storage_temp_tutorial.ipynb


Update README.md including primitive types usage

Related to #446

:rocket: This PR description was created by Ellipsis for commit f571fbee0418422de7920fadf592ecfb87a6f79f.

Summary:
This PR updates the README.md to include a section demonstrating the usage of primitive types (str, int, float, bool) as response models in the Instructor library.
Key points:

Added a new section to README.md demonstrating the usage of primitive types as response models.
Included a code snippet showing a chat completion request using a boolean response model.

Generated with :heart: by ellipsis.dev

I think including that example will be enough for people to understand that instructor can handle all kinds of primitive types


AA: Expand AA APIs to support CC trusted APIs

Hello,
Confidential Computing (CC) API group defines unified and vendor agnostic and Trusted Computing Group (TCG) compliant CC trusted APIs, like Intel TDX, AMD SEV SNP, TPM, etc. It helps the diverse applications to access and process the trust states which were represented by integrity measurement, event record, and report/quote in the confidential computing environment.
The key CC trusted APIs include:

get_cc_report: get a signed attestation report in a TEE, such as TDX Quote, TPM Quote, and AMD attestation report.
get_cc_measurement: get the measurement registers in a TEE, such as TDX RTMRs, TPM PCRs, and AMD SEV SNP launcher measurement.
get_cc_eventlog: get the recorded event logs in a TEE, which follow TCG specification and support Canonical Event Log (CEL).
get_measurement_count: get the count of the measurement register.
get_default_algorithm: get the default digest algorithms supported by a trusted foundation.
replay_cc_eventlog: replay the event logs against measurement registers to prove the integrity of the event logs.

More information on these functions can be found here: https://github.com/cc-api/cc-trusted-api/blob/main/common/rust/cctrusted_base/src/api.rs
With these common APIs, the workload can easily get the measurements directly in a common interface in each kind of TEE, furthermore, within an Integrity Measurement Architecture (IMA) enabled system, the measurement can be used as evidence of a trusted chain for all applications. More information can be found in CCC Attestation SIG presentation or CCC TAG presentation.
AA has attestation interfaces for getting evidence, tokens, etc.  CC APIs can be added as a trait in the same level as Attestation APIs, here is a proposal to expand AA APIs to support CC trusted APIs.

Comments are welcome!

Hi,
on top of cc-api, a ttrpc/grpc is preferred, and on top of ttrpc/grpc, a http/https/restful api is preferred.
so the whole flow might look like below:
cc-api --> grpc/ttrpc (attestation agent api layer one) --> http/https/restful api (attestation agent api layer two), then  attestation agent api --> remote (in docker)/local(local binary) attestation service

I'm not sure I totally understand the proposal. Is the idea to have the AA expose this API to workload containers? That might be a non-starter. We need to be very careful about exposing evidence to containers, which aren't necessarily measured. It can be dangerous to expose valid hw evidence to unknown workloads, especially if the evidence is relatively generic.
The pattern for exposing the guest components to the workloads is to use the ASR. I'm not sure how that squares with this. Note that we already have an endpoint to expose attestation reports with this pattern. It is disabled by default. For platforms that support runtime measurement, the report usually contains these fields.
Can you be more clear about what we are missing that this proposal would enable? Btw it doesn't seem like this API has been very widely adopted.

I'm not sure I totally understand the proposal. Is the idea to have the AA expose this API to workload containers? That might be a non-starter. We need to be very careful about exposing evidence to containers, which aren't necessarily measured. It can be dangerous to expose valid hw evidence to unknown workloads, especially if the evidence is relatively generic.

The AA can decide what should be exposed to containers. Could you please share what dangerous of hw evidence. Actually, workload can get all of these evidence without this API with proper permission.

The pattern for exposing the guest components to the workloads is to use the ASR. I'm not sure how that squares with this. Note that we already have an endpoint to expose attestation reports with this pattern. It is disabled by default. For platforms that support runtime measurement, the report usually contains these fields.

What is ASR? (Sorry I did not find it in AA code, could you please share a little more)? We did not change existing pattern, CC trusted API just to expose evidence by following existing AA pattern.

Can you be more clear about what we are missing that this proposal would enable? Btw it doesn't seem like this API has been very widely adopted.

This proposal is used to expose the launch/runtime evidence in unified API and follow TCG (Trust Computing Group) industrial standard. So it can simplify the AA to handle different TEE, like CCEL event log or TPM2 event log.


fix: don't remove entities when car is asleep

This ensures the following entities aren't suddenly removed if the integration is reloaded (or HA restarted) while a vehicle is asleep:

heated steering wheel
sentry mode
homelink

Instead of conditionally creating these entities during setup, they will always be added. However, on first install (when wake_if_asleep is used), if any of these entities are not available they will be disabled by default. This ensures that entities which are not part of the vehicle will not be enabled (not visible and no logging), but also provides the option that a user could enable it if it was somehow wrongly disabled.
Once enabled, the entity would not self-disable upon reload even if it is unavailable: Fixes #293 (note these entities would show unavailable if reloaded while the vehicle is asleep, but would automatically become available again next time it's online)
Additionally this PR fixes dynamic updates of the availability of these items while the car is online (and reflect the last state while car is offline).
And I threw in a small fix to remove the units.is_metric reference which is being deprecated soon (I happened to notice this warning while testing)

@shred86 for vis, this should fix the remaining entities disappearing issues, this seemed the next best thing given the option codes aren't reliable.

Back out the is_metric change please as there is an existing pr and I don't want to force a ha min update yet since that change is very recent.

Back out the is_metric change please as there is an existing pr #343 and I don't want to force a ha min update yet since that change is very recent.

Ahh I didn't realize it was so recent. Done.

Since this is an area with active issues, can you also put in some tests covering these sensors being created with tests for both cases that cause then to be enabled or disabled?

Since this is an area with active issues, can you also put in some tests covering these sensors being created with tests for both cases that cause them to be enabled or disabled?

Took me a bit to work this out, let me know how that looks.

Looks good. Thanks for that.


Timestamp type not being filtered

I am using Oracle jdbc and trying to get the date filter to work but there has been many issues.
Here is my current config -->> at first it was a class error now its fine. Then there were incompatible types ruby and java strings. So I added the to_char. Now its not recognizing the timestamp. Could it be because of the type?
Name                                      Null?    Type

CREATION_TIME                             NOT NULL TIMESTAMP(6)
input {
jdbc {
jdbc_driver_library => "logstash-1.5.0/ojdbc6.jar"
jdbc_driver_class => "Java::oracle.jdbc.driver.OracleDriver"
jdbc_connection_string => "jdbc:oracle:thin:@//"
jdbc_user => ""
jdbc_password => ""
statement => "SELECT to_char(creation_time,'YYYY-MM-dd HH24:MI:SSxFF TZR') as logStoreTime from log where creation_time > :sql_last_start"
record_last_run => true
last_run_metadata_path => "/.logstash_jdbc_last_run"
type => "log"

}
}
filter {
grok {
match => {"logStoreTime" => "(?\d{4}-\d{2}-\d{2} \d{2}:\d{2}:\d{2}.\d{6} +\d{2}:\d{2})"}
}
# date {
#   locale => "en"
#   timezone => "GMT"
#   match => [
#     "logStoreTime" , "YYYY-MM-dd HH:mm:ss.SSSSSS Z"
#   ]
# }
}
sample output of what I am getting:
{
"logstoretime" => "2015-08-04 18:34:14.747000 +00:00",
"@version" => "1",
"@timestamp" => "2015-08-06T12:52:15.850Z",
"type" => "test",
"tags" => [
[0] "_grokparsefailure"
]
}
{
"logstoretime" => "2015-08-04 18:34:18.661000 +00:00",
"@version" => "1",
"@timestamp" => "2015-08-06T12:52:15.854Z",
"type" => "test",
"tags" => [
[0] "_grokparsefailure"
]
}
And I know the grok pattern will match it has been tested on http://grokdebug.herokuapp.com/

to match the logstoretime field into the @timestamp field, there is no need for grok parsing it.
here is an example config you can check out to see it run through parsing the timestamp
input {
  generator {
    lines => ["2015-08-04 18:34:18.644000 +00:00"]
    count => 1
  }
}
filter {
  date {
    match => ["message", "YYYY-MM-dd HH:mm:ss.SSSSSS Z"]
  }
}
output {
  stdout { codec => rubydebug }
}

output :
{
    "message" => "2015-08-04 18:34:18.644000 +00:00",
    "@timestamp" => "2015-08-04T18:34:18.644Z"
}

Through this test, I believe this time format string should work: YYYY-MM-dd HH:mm:ss.SSSSSS Z

I understand. I only put the grok match to see if its picking up from the table and its not! I even tried setting it to greedydata and it will not print out the field name I set. Here is what I changed with a mix of your code:
input {
jdbc {
jdbc_driver_library => "/logstash-1.5.0/ojdbc6.jar"
jdbc_driver_class => "Java::oracle.jdbc.driver.OracleDriver"
jdbc_connection_string => "jdbc:oracle:thin:@//"
jdbc_user => ""
jdbc_password => ""
statement => "SELECT to_char(creation_time,'YYYY-MM-dd HH24:MI:SSxFF TZR') as StoreTime from log where creation_time > :sql_last_start"
record_last_run => true
last_run_metadata_path => "/sincedbpath/.logstash_jdbc_last_run"
type => "test"

}
}
filter{
grok {
match => {"StoreTime" => "%{GREEDYDATA:logStoreTime}"}
}
date {
match => ["logStoreTime", "YYYY-MM-dd HH:mm:ss.SSSSSS Z"]
}
}
output{
stdout {codec => rubydebug}
}
What I get:
{
"storetime" => "2015-08-04 18:34:18.661000 +00:00",
"@version" => "1",
"@timestamp" => "2015-08-06T17:51:44.348Z",
"type" => "test"
}
If I try with bare-bone config -> same input with jdbc but with your filter and output its the same:
{
"storetime" => "2015-08-04 18:34:18.661000 +00:00",
"@version" => "1",
"@timestamp" => "2015-08-06T17:56:44.676Z",
"type" => "test"
}
Do you think it could be the data type? Really frustrating problem especially when I know everything else is working properly.


Start using the bugbug HTTP service

It's still a work in progress but I get the same output running python3 -m auto_nag.scripts.component -d on master and on this branch

Coverage decreased (-0.1%) to 25.602% when pulling 4e5e5330f8eaae60750c92de42db338a0d42ec0e on Lothiraldan:use-bugbug-http-service into a867da4acd4c5ed257df65ca38b4896eb53122d5 on mozilla:master.

All scripts are running


Detect clang-cl as MSVC

The compiler identification checks in src/optick.h currently assume the
user is on a Unix platform is compiling with Clang. This isn't the case
when using Clang's MSVC compatible frontend (clang-cl).
This is a simple fix that checks for MSVC first, which both cl.exe
and clang-cl.exe will identify as.

Fixes https://github.com/bombomby/optick/issues/104.


Support assignment between structs

If x and y are structs of the same type, y = x should copy all the fields, maybe using something like memcpy.
A test that should pass:
  assert(9, ({ struct {int a; int b; int c;} x = {2,3,4}, y = {0,0,0}; y = x; y.a + y.b + y.c; }),
              "struct {int a; int b; int c;} x = {2,3,4}, y = {0,0,0}; y = x; y.a + y.b + y.c;");

Right now it returns 2 (so we are only copying the first field).

hi, i'm interested to help implement this! do you have any pointers?

Hi @youbitchoc! I think what needs to happen is, this bit of code in codegen.c...
  case ND_ASSIGN:
    gen(node->rhs, depth);
    fix_bool(node->ty);
    gen_lval(node->lhs, depth + 2);
    store(node->ty);
    return;

has to become a bit smarter. It should check if ty->kind == TY_STRUCT and if so (generate code to) do a memcpy of ty->size bytes. gen_lval(node->rhs, depth) is a pointer to the source and node->lhs is a pointer to the target.
For the memcpy, maybe it can be an "intrinsic" like how sign extension is handled (see need_sext_helper).

is it possible to modify the store function to handle ty->sizes other than 1 and 2?
// Expects "newval addr" on the stack and leaves "newval".
static void store(Type *ty) {
  if (ty->size == 1) {
    op(STA | flag_k);
    op(POP2);
  } else {
    op(STA2 | flag_k);
    op(POP2);
  }
}

the opcodes will probably be much more complex though...

I think it's a bad idea to solve this at the level of store. That function handles a scenario where the new value is on the stack. But in an assignment between structs like y = x, we don't want the value (i.e. all the fields) of x to be put on the stack, only its address (gen_lval).

mm! i tried implementing it and realize now that contorting the stack is horribly inefficient
since struct size is known at compile time, could it be better to bake in the "memcpy" instead of outsourcing to an intrinsic?

Possibly, yes! That sounds worth exploring. But I wouldn't shy away from doing it the simple way first.


PT-1328 - Fixes to the Gem for ENV Variables and Rails Bits

📝 Review Effort
Estimated effort by an experienced developer to review this PR: 3/5.

The introduction of new methods for environment handling requires careful review to ensure they cover all necessary scenarios.
Changes in the initialization logic of PayrixGateway need to be verified for compatibility and correctness.
New tests need to be reviewed for completeness and accuracy in covering different environment settings.

🔎 Overview

Added new methods in ActivemerchantPayrix to determine the environment and check if it's a test environment, removing the dependency on Rails.
Updated PayrixGateway initialization to use the new environment methods, ensuring the gem remains stand-alone.
Enhanced test coverage by adding tests for the new environment detection methods, ensuring various scenarios are covered.
Simplified the test token assignment in the spec helper by removing unnecessary freeze.

✍ File Changes
📄 lib/activemerchant_payrix.rb - +12/-0
Summary: Add environment detection methods to ActivemerchantPayrix module

Changes
Added methods to determine the environment and check if it's a test environment.  Introduced a private method to check the presence of environment variables.

📄 lib/activemerchant_payrix/active_merchant/billing/payrix_gateway.rb - +1/-3
Summary: Remove Rails dependency and update initialization

Changes
Removed the Rails dependency for environment detection.  Updated initialization to use the new environment methods.

📄 spec/active_merchant/billing/payrix_gateway_spec.rb - +1/-1
Summary: Update tests for private token usage

Changes
Updated tests to use environment variable directly for private token.

📄 spec/activemerchant_payrix_spec.rb - +72/-0
Summary: Add tests for environment detection methods

Changes
Added tests for new environment detection methods.  Covered various scenarios for environment variable settings.

📄 spec/spec_helper.rb - +1/-1
Summary: Simplify test token assignment in spec helper

Changes
- Removed unnecessary freeze from test token assignment.

🤖 This description was AI-generated by Devoro

Since pipeline isn't in place, I've copied the Summary from the spec run below.
Finished in 0.07102 seconds (files took 1.11 seconds to load)
41 examples, 0 failures


[TuyaWebPlatform] Authentication error: you cannot auth exceed once in 180 seconds

I get
[TuyaWebPlatform] Authentication error: you cannot auth exceed once in 180 seconds
After which, the plugin doesn't try to re-authenticate, as far as I can tell. At least not in a short time span (i.e. minutes, not hours).
As a consequence the tuya accessories are not operable through homebridge.
Steps To Reproduce
I am not entirely sure what the steps would be, other than a frequent restart of homebridge as I am developing on it.
Plugin Version
v1.1.3
Homebridge Config
       {
           "name": "TuyaWebPlatform",
           "options": {
               "username": REDACTED,
               "password": REDACTED,
               "countryCode": "1",
               "platform": "smart_life"
           },
           "defaults": [
               {
                   "id": "d63fb462-a193-4a90-a24b-f3705990a0f9",
                   "device_type": "switch"
               }
           ],
           "scenes": false,
           "_bridge": {
               "username": "0E:BE:65:C9:D3:A1",
               "port": 50405
           },
           "platform": "TuyaWebPlatform"
       },

Device Config
N/A as it's not a problem with any device, it's a problem with tuya authentication
Additional Context
I think that the problem comes from https://github.com/milo526/homebridge-tuya-web/blob/9ba39bd8fccb94a5fc24b2367e088b241e069d53/src/api/service.ts#L198
Here you check for an exact error match. I am not sure whether they changed the Tuya API behavior in terms of error string returned, but now I'm seeing 180 instead of 60 in that same error string (as per title of this Issue).
Something I didn't get to understand is why throwing an error if there isn't a valid token, rather than getting a new one or refreshing it. E.g. here: https://github.com/milo526/homebridge-tuya-web/blob/9ba39bd8fccb94a5fc24b2367e088b241e069d53/src/api/service.ts#L41
This is more for my personal understanding than anything else.
I also have a potential fix ready. Sorry I don't speak typescript or javascript and I'm sure my fix sucks but I hope it gives you a good pointer and a potential solution to a more general problem with authentication.
I'll link the PR here as soon as I can test it out.
Thanks!!

I run into this same issue frequently

https://github.com/milo526/homebridge-tuya-web/pull/537/files

I run into this same issue frequently

Can you please try out my fix?
https://github.com/milo526/homebridge-tuya-web/pull/537


Hubot did not respond after some time later (eg: one day)

node version: 8.9.4
rocketchat version: 0.61.0
hubot-rocketchat version: 1.0.12
hubot log info:

Fixed.
Probably because our proxy server discard the bot session.


Devtools enabled by default

Coverage increased (+0.05%) to 81.28% when pulling 73cddbe0842581742cd87b5c0c77c178d6d3ce53 on eatonphil:default-devtools-enabled into 9c1aed18395b20953f854e648ba463a47465142a on linode:master.


Add AMQP 1.0

https://github.com/xinchen10/awesome-amqp
AMQP 1.0 is an OASIS standard for business messaging. It is also popular in the cloud messaging and the IoT space.

[x] I have read and understood the contribution guidelines and the instructions for creating a list.
[x] This pull request has a descriptive title.
The list I added

[x] is not a duplicate,
[x] has been around for a few weeks,
[x] only has awesome items with descriptions,
[x] contains the awesome badge on the right side of the list heading,
[x] has an appropriate license,
[x] has contribution guidelines,
[x] has been checked for inconsistent formatting, spelling and grammar, and
[x] has been added at the bottom of the appropriate category.

has been around for a few weeks,

The point of the checkboxes is that it should actually apply. Your list has not been around for a few weeks...  😩🌴

Maybe a fixed number of weeks is needed?


bugfix SEP-31: improve documentation on the TransactionEvent fields and fix events values in the code

PR Checklist
PR Structure

[x] This PR has reasonably narrow scope (if not, break it down into smaller PRs).
[x] This PR avoids mixing refactoring changes with feature changes (split into two PRs
otherwise).
[x] This PR's title starts with name of package that is most changed in the PR, ex.
paymentservice.stellar, or all or doc if the changes are broad or impact many
packages.

Thoroughness

[x] This PR adds tests for the most critical parts of the new functionality or fixes.

What
Update the code and the Events Schema description.

Add the id field to StellarId event schema.
Improve documentation on the TransactionEvent fields and fix events values in the code. The following properties were off and their descriptions were updated to make it clearer what they're meant for:

TransactionEvent.source_account: is the source of the Stellar payment related to the SEP-31 transaction.
TransactionEvent.destination_account: is the destination of the Stellar payment related to the SEP-31 transaction.
TransactionEvent.customers.sender: is the id of the SEP-12 sending customer that's related to this transaction.
TransactionEvent.customers.receiver: is the id of the SEP-12 receiving customer that's related to this transaction.
TransactionEvent.creator: is the stellar_account:memo used in the jwt token that authenticated and created this SEP-31 transaction.

Why
Close #387
Close #388
Further discussion
These fixes were based on this Slack thread.

Reference Server Preview is available here:https://anchor-ref-pr412.previews.kube001.services.stellar-ops.com/SEP Server Preview is available here:https://anchor-sep-pr412.previews.kube001.services.stellar-ops.com/

Reference Server Preview is available here:https://anchor-ref-pr412.previews.kube001.services.stellar-ops.com/SEP Server Preview is available here:https://anchor-sep-pr412.previews.kube001.services.stellar-ops.com/

Reference Server Preview is available here:https://anchor-ref-pr412.previews.kube001.services.stellar-ops.com/SEP Server Preview is available here:https://anchor-sep-pr412.previews.kube001.services.stellar-ops.com/

Reference Server Preview is available here:https://anchor-ref-pr412.previews.kube001.services.stellar-ops.com/SEP Server Preview is available here:https://anchor-sep-pr412.previews.kube001.services.stellar-ops.com/

Reference Server Preview is available here:https://anchor-ref-pr412.previews.kube001.services.stellar-ops.com/SEP Server Preview is available here:https://anchor-sep-pr412.previews.kube001.services.stellar-ops.com/

Reference Server Preview is available here:https://anchor-ref-pr412.previews.kube001.services.stellar-ops.com/SEP Server Preview is available here:https://anchor-sep-pr412.previews.kube001.services.stellar-ops.com/

Reference Server Preview is available here:https://anchor-ref-pr412.previews.kube001.services.stellar-ops.com/SEP Server Preview is available here:https://anchor-sep-pr412.previews.kube001.services.stellar-ops.com/

Reference Server Preview is available here:https://anchor-ref-pr412.previews.kube001.services.stellar-ops.com/SEP Server Preview is available here:https://anchor-sep-pr412.previews.kube001.services.stellar-ops.com/

Reference Server Preview is available here:https://anchor-ref-pr412.previews.kube001.services.stellar-ops.com/SEP Server Preview is available here:https://anchor-sep-pr412.previews.kube001.services.stellar-ops.com/

Reference Server Preview is available here:https://anchor-ref-pr412.previews.kube001.services.stellar-ops.com/SEP Server Preview is available here:https://anchor-sep-pr412.previews.kube001.services.stellar-ops.com/

Reference Server Preview is available here:https://anchor-ref-pr412.previews.kube001.services.stellar-ops.com/SEP Server Preview is available here:https://anchor-sep-pr412.previews.kube001.services.stellar-ops.com/

Reference Server Preview is available here:https://anchor-ref-pr412.previews.kube001.services.stellar-ops.com/SEP Server Preview is available here:https://anchor-sep-pr412.previews.kube001.services.stellar-ops.com/

Reference Server Preview is available here:https://anchor-ref-pr412.previews.kube001.services.stellar-ops.com/SEP Server Preview is available here:https://anchor-sep-pr412.previews.kube001.services.stellar-ops.com/


Animation of NavDrawer

In https://github.com/react-toolbox/react-toolbox/blob/dev/components/layout/theme.scss all animations use the $animation-curve-default (cubic-bezier(0.4, 0, 0.2, 1).
According to the Specs of Material Design (https://material.google.com/motion/duration-easing.html#duration-easing-natural-easing-curves) we should use different cubic-bezier-curves.
For incoming objects (navDrawer is actvie) the $animation-curve-linear-out-slow-in should be used and for objects leaving the screen the $animation-curve-fast-out-linear-in.
Maybe the animation could be renamed to the following (would be easier to understand when the animation is used):
$animation-standard: $animation-curve-fast-out-slow-in;
$animation-deceleration: $animation-curve-linear-out-slow-in;
$animation-acceleration: $animation-curve-fast-out-linear-in;
$animation-sharp: cubic-bezier(0.4, 0, 0.6, 1) !default;

Furhtermore the animations (especially on desktop) should be faster than 0.35ms:

Desktop animations should be faster and simpler than their mobile counterparts. These animations should last 150ms to 200ms.

It makes sense. Do you want to PR?


Potential bug with array searchable attributes

Describe the bug
Original discord thread
Was helping a person on how to make an array of object properties searchable and encountered an odd potential bug. Given a simple set of objects that includes a translations array with a title the text in the title can be searched if configured correctly in searchableAttributes but the word Ability gives no matches. All other words seem to be searchable.
To Reproduce
Steps to reproduce the behavior:

Download message.json
Create a new index with default settings
Add translations.title as the only searchable attribute
Searching for to accept criticism gives matches
Searching for criticism, gives matches
Searching for Ability, gives no matches

Expected behavior
Simply put, I'm expecting Ability to match several documents.
Screenshots

Meilisearch version:
v1.5.0
Additional information that may be relevant to the issue.
Runs in docker

I reproduced the bug on the latest main.
It's really strange because no results are returned with "Ability" when this document exists:
{
      "id": "d81983f7-f7dc-4ddd-8fec-4e6cc39a7bd0",
      "translations": [
        {
          "id": "064ee085-cab1-44f4-8908-3ff52c1f677b",
          "languageCode": "EN",
          "title": "Ability to keep deadlines"
        },
        {
          "id": "ec40ab8f-ec31-4248-af78-aa9490f0f6e7",
          "languageCode": "HY",
          "title": "Ժամկետները պահպանելու ունակություն"
        }
      ],
      "type": "SOFT",
      "title": "Ability to keep deadlines"
    }

But I do get results when I look for any other word even when they're at the start of the document like "Constructive":
{
      "id": "eaa4e19d-adf4-49bf-adc3-1d98d6ed7e13",
      "translations": [
        {
          "id": "dff49658-5449-4c26-899a-8c0f3891560c",
          "languageCode": "EN",
          "title": "Constructive feedback giving"
        },
        {
          "id": "95cbebfb-0b4b-4c3e-9cb4-4c94867c125e",
          "languageCode": "HY",
          "title": "Կառուցողական հետադարձ կապի տրամադրում"
        }
      ],
      "type": "SOFT",
      "title": "Constructive feedback giving"
    }

The only difference I can see between Ability and any other word is that there are 8 documents starting with Ability without only one or two for every other word.

If you point me to the area of code that likely does this, happy to spend time and debug it.

any news? :)

Sorting also works incorrectly
https://github.com/meilisearch/meilisearch/assets/1781506/c128fa72-8a24-499a-b704-f394fb191d43

Hey @jzabroski,

Sorting also works incorrectly

Which version are you using?
We fixed a bug in the latest version of meilisearch (v1.6.2)

Hey @NarHakobyan,
After updating to the latest version, have you re-indexed your documents?
Since the bug corrupts the database, you need to re-index everything to see the fix.
The easiest way to do that if you can’t clear your index and send back all your documents is to:

Remove all your filterable attributes
Wait until the task is fully processed; this is very important; otherwise, there is a risk meilisearch understand what you’re doing and optimize it out
Send back all your filterable attributes

If you updated your version through a dump, none of this applies.

Hello @Fronix
Do you still have the issue with v1.10.0?

Currently not able to test but maybe https://github.com/NarHakobyan, who is the user I was helping with the issue can test?
Sent from Outlook for Androidhttps://aka.ms/AAb9ysg

From: Clémentine @.>
Sent: Tuesday, September 17, 2024 10:23:52 AM
To: meilisearch/meilisearch @.>
Cc: Oscar Martin @.>; Mention @.>
Subject: Re: [meilisearch/meilisearch] Potential bug with array searchable attributes (Issue #4244)
Hello @Fronixhttps://github.com/Fronix
Do you still have the issue with v1.10.0https://github.com/meilisearch/meilisearch/releases/tag/v1.10.0?
—
Reply to this email directly, view it on GitHubhttps://github.com/meilisearch/meilisearch/issues/4244#issuecomment-2354865764, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AAE2DDBW72RXLWJONRWM6DLZW7RJRAVCNFSM6AAAAABAD5YMDSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGNJUHA3DKNZWGQ.
You are receiving this because you were mentioned.Message ID: @.***>

After updating to the latest version, have you re-indexed your documents?

I suspect this is the key and why I initially offered my help to test this.  I think the README should be clearer about refreshing indices when ugprading meilisearch.  This is something I have discussed / hinted at in the past but would like to see movement on as I think it would help your core team members a lot.  I am not a big brain, just somebody who likes quick wins.

@jzabroski It's not common to have to reindex everything after upgrading Meilisearch. It's due to a specific bug, and we try to make clear in the related release notes. Sorry for the inconvenience.
Let us know @NarHakobyan


Plan and execute a load test with 500 devices

Do you want to create load test which will fire requests to nRF Cloud server or just to our MQTT bridge server? The scenarios will be similar to the simulator device. The current simulator device cli performs the followings
Once

Location

Every 10 seconds

Battery
Gain

Every 1 minute

Update device info

Please add test plan and metrics here.

Plan
Our target is to achieve 500 concurrent devices. So, we will generate 500 devices with in 120 seconds along with web socket connections. Each device will publish solar and battery data every 10 seconds and ground fix location once.
Once we reach the 500 concurrent devices, we will keep it running for 15 minutes. Then, close all connections
Metric

Lambda success rate and error count
MQTT bridge CPU and memory utilization
Shadow fetches
Device messages

Looks good, thank you!


Issue with ethEvent function - SYSTEM_EVENT doesn't work but ARDUINO_EVENT does

I have a WT32-ETH01 module, and I compiled the program in PlatformIO for it to work via Ethernet. However it didn't seem to be able to make a connection to the Icecast server, despite obtaining an IP address and being able to make a DNS request.
I set the debug level to 5 so that I get all messages in the terminal, and I saw that some lines showed that it got an IP address, but one showed just IP =  without the address. I looked through the code and found that this should display the address from ipaddress variable, which is set in the ethEvent function.
Then I saw that what should have been displayed as:
ETH Started
ETH cable connected
IPv4: [address], 100 Mbps, FULL_DUPLEX
actually displayed as:
ETH event 18
ETH event 20
ETH event 22
So the ethEvent function didn't detect the events properly. I have tested the WT32-ETH01 before using some example code, and it was working, and I noticed that it uses:
ARDUINO_EVENT_ETH_START
ARDUINO_EVENT_ETH_CONNECTED
ARDUINO_EVENT_ETH_GOT_IP
ARDUINO_EVENT_ETH_DISCONNECTED
ARDUINO_EVENT_ETH_STOP
instead of:
SYSTEM_EVENT_ETH_START
SYSTEM_EVENT_ETH_CONNECTED
SYSTEM_EVENT_ETH_GOT_IP
SYSTEM_EVENT_ETH_DISCONNECTED
SYSTEM_EVENT_ETH_STOP
So I replaced these and now everything is working fine.
However I thought that you must have had it working with SYSTEM_EVENT_... instead of ARDUINO_EVENT_..., otherwise you would have used ARDUINO_EVENT_... instead. So what could be causing it to not work in my case?

You ar right about renaming the events.  It has something to do with newer versions of some libraries.  I got an IP address now, but still no connection.  I will try to find a solution.

Thank you for answering. So would it be better if I leave these events as ARDUINO, or change them back to SYSTEM and use an older library?

The best way is to use the new definiotions.

Thanks. This issue is solved for me now, I'm not closing it yet because I'm not sure if you want it closed.

So you do have connection with the server?  I still have problems, but it could be the WT32 itself.

I can connect and play sound, but only with an MP3 stream as described in #105.
I only remember changing the board to wt32-eth01 and the COM port in platformio.ini, and later changing the SYSTEM events to ARDUINO when troubleshooting before it started to work. When I'm back at home I will check if I changed anything else.


Need to manually re-call getInitialProps of sub-components

As described here: https://github.com/zeit/next.js/issues/159#issuecomment-257318970 and as far as I understand, if some React component has a getInitialProps, then all of its parents are condemned to need it too, and each parent in turn needs to call getInitialProps on their children, in the right order, making sure not to duplicate the work between the different levels of ancestry (the linked issue shows the case of a higher-component style, but the same applies when passing components as React children the normal way).
Forgetting one of these calls can lead to silent bugs such as not having server-side rendering, and this code repetition can hinder proper componentization (one of React's key patterns).
From an end-user perspective, just like with React component lifecycle methods such as componentWillMount etc, IMHO the developer should trust that getInitialProps will be called no matter what, as long as it's spelled properly.
Could Next.js handle getInitialProps as part of the React component lifecycle or implement the same kind of magic to make sure it gets called whenever defined in a component?
I'm new to SSR and Next.js, so apologies if this makes no sense 😄

I think this is mainly an issue when using a HOC to wrap page components, e.g. for adding a navigation bar or site wide footer etc. Perhaps if we went down the route being discussed in #88, where a user could supply a global component (_layout.js for want of a better name), then this component could perhaps extend a special version of React.Component that automatically calls getInitialProps of the child component(s)? Whether this would work depends on how exactly the issues described in #88 are solved in the end.

You can write your page components with HOC like the following:
import React from 'react'
import hoc from '../components/Hoc'

const Component = hoc(() =>
{this.props.value}
)
Component.getInitialProps = () => {
  return { value: 'my value' }
}

export default Component

I think there is no much difference whether if you use HOC or not.

I agree, but if it's a sub-component which is wrapped in a HOC (in my case, an Apollo HOC), then this page will have to make sure to call it from here, otherwise the effects are unpredictable. It took me time to figure out these subtle bugs, I wouldn't wish every newcomer to have to figure it out the same way.
For example here is my current working code, it already uses two HOCs,page and apollo:
https://github.com/sedubois/realate/blob/master/pages/discover.js
If I decide to change discover.js to the following:
import React from 'react';
import Users from '../containers/Users';
import page from '../components/Page';
const Discover = () => (

    <Users />

other fancy stuff

);
export default page(Discover);

then I will get a cryptic error ReferenceError: window is not defined thrown at containers/Apollo.js:38 (because the WrapWithApollo constructor will be called directly without having first called its getInitialProps). It takes quite some time to figure out that getInitialProps should be added to Discover and should in turn call getInitialProps on Users. Besides being hard to debug, it also adds unnecessary complexity for the end-user.
Don't get me wrong, I think Next.js is awesome 😄 but this makes it a bit hard to scale and leads to some frustration.

I agree that it'll be hard to figure out the bug.
I think It'd be cool if we can display warning whengetInitialProps was detected on sub-components. Actually, I'm not sure if it's possible to do though.

That'd be cool, and I'd say if we can auto-detect, then we could as well call these getInitialProps instead of forcing the user to explicitly call them. I won't pretend that I know how though 😄 but I guess it should be possible as React seems to do something like that with their component lifecycle methods?

@nkzawa what are your thoughts on my proposal here? https://github.com/zeit/next.js/issues/186

@nkzawa you could probably traverse the component tree prior to calling getInitialProps on the root component to detect any children that define it (or not), but I'm not sure what value that would add and could easily become a very expensive operation.

I don't know much and haven't tried next.js yet, but if I remember correctly react-redux-universal-hot-example was using a fetchData method to fetch data asynchronously from its components. At some point the whole component tree was traversed to detect any fetchData method anywhere in the tree. This in-house fetchData has been replaced with a package called asyncConnect which uses redux.
It seems like https://github.com/ericclemmons/react-resolver is doing something similar though without redux.
Don't know if this helps really but we never know.

@dbismut redux-connect (forked from redux-async-connect) looks promising 👍  However that requires a Redux store, and although I think that's the way to go, I'm not sure the Next.js team would have the same opinion? @nkzawa

@sedubois that's why react-resolver could be a more agnostic way to go.

@dbismut thanks yes, I didn't pay enough attention, I thought the project was inactive as no commit since 3 months. We should try to build an example.

I checked how react-resolver works but it requires to render a component twice on server rendering, which would be expensive and introduce unexpected side effects.
We'd have to do the same for supporting getInitialProps of descendant components, and I think it's unacceptable. getInitialProps is required only for top-level components because no one can provide props to them without a provider. So basically, I think having getInitialProps or react-resolver to descendant components wouldn't make sense.
Maybe we can still display warnings by traversing the component tree after rendering (not before getInitialProps call since we need props to render the tree),  and these expensive operations would be acceptable if it's only for development.

So basically, I think having getInitialProps or react-resolver to descendant components wouldn't make sense

@nkzawa I might have misunderstood, but are you saying that we shouldn't be using getInitialProps in any components except the pages/? But what about the components included from there?
For example, how would I bind my Apollo HOCs, without getInitialProps? (NB: they are already two levels down in my component hierarchy.)

nope, I meant next.js shouldn't try to handle getInitialProps defined in descendants.
I think your HOC would become a top level component, or the getInitialProps would be manually called on top level one, which is no problem.
So it seems we shouldn't add warnings too, if people'd like to merge getInitialProps from wrapped components.

@nkzawa as highlighted in previous comments and e.g in @luisrudge's implementation (improved by @impronunciable) of an authentication flow, (see commit), not only are we bound to repeatedly forget calling the child getInitilaProps, but it also makes the code much less clean and more verbose. I'm not saying I have a clean alternative to propose at this point, but it really is lots of time lost for newcomers like me. Minimalism is good but IMHO it should enhance the DX, not hinder it.

@nkzawa Manually handling children's getInitialProps in the parent also means that the child data needs to be assembled and stored within the parent, only to then be re-provided to the children (for example see https://github.com/zeit/next.js/issues/186#issuecomment-259956419). Would be great to get rid of this data roundtrip between children and parent (is also bug-prone).
If somehow feasible, the above example could be rewritten as:
import connectInitialProps from 'next/connect';

const Child = ({ name }) =>
{name}
;
const Child1 = connectProps(() => ({ name: 'Child1' }))(Child);
const Child2 = connectProps(() => ({ name: 'Child2' }))(Child);

export default () => (

    <Child1 />
    <Child2 />

);

AFAIK Redux and Apollo allow that kind of thing thanks to their store provider. If Next doesn't want to force the use of a store, maybe we could find a middle ground where Next supports getting data from a store if one exists, otherwise works as before?

This is a tricky and interesting issue. It gets even more complicated: imagine components with getInitialProps, which get only loaded conditionally, based on some other data loaded in an ancestor's getInitialProps. One would need to call each component's getInitialProps just in time before rendering it. I don't know if react allows for such a thing.

I agree with @sedubois here, the need for getting data deep into the component hierarchy isn't easily dismissed. Imagine for example a list of items, one of which should be "expanded" with more data. In the top getInitialProps you fetch the data for the list, and in the individual component's getInitialProps you'd check whether the component is expanded and load more data if needed.

@nmaro the "ListItem" component could be passed additional props when it is expanded. With the addition of React's context you have everything you need to pass the data down.

True @amccloud, but I see the following problems with this approach:

Polluting react's context with data is discouraged
More importantly, you loose modularity: the top component has to know all the data it will need to load for all the subcomponents. For every change of a component's data needs, one needs to change the data subscriptions in all pages that use that component.

@nkzawa please correct me if I'm wrong:
getInitialProps is only for the initial server side render. It is the only way to get request/env data into the render tree. If necessary, anything derived from that request data could be passed to deeper through props or context.  For your typical data fetching needs, you are free to use tools like redux, relay, and react-apollo to connect to any of your components directly to a data source.

@amccloud do you mean just passing down some context data, and then fetching the actual data down in the hierarchy? I don't think it's possible, of course would be great to hear otherwise.
I believe all the async/data-fetching operations on the server have to happen in getInitialProps - which I think is the problem.
Page > ... > ... > ... > ... > Component
Imagine Component needs some graphql data with a query defined specifically for that component.
The problem is that you need to load Page.getInitialProps and then pass the data down to that Component.

Hi. I'm following the development of next with great interest and I wanted to chime in on this issue.
In my opinion, architecting even a moderately complex web application while having to hoist each pages's data to the root component will be very hard to handle cleanly. If a solution can be found then it would be much better.
Just off the top of my head, could each component simply await on data in the componentWillMount hook, therefore blocking the entire rendering process until all the data is available?
Clearly we would only want to do this on the server, so perhaps an API can be exposed that components can use.

@amccloud getInitialProps is not only for server side rendering (called on client too). Others are correct I think.

Anyway, this issue shows that it really is a problem with react, not next.js: https://github.com/facebook/react/issues/1739

@nkzawa I didn't mean to imply that getInitialProps is only called on the server. What I'm suggesting  is that components could simply block the rendering process using an await while waiting for data on the server, so that renderToString returns with the fully rendered component.
On the client we wouldn't want to use an await. We want do render everything that we can and update state/props once the data's available.
next could provide an API to make that more seamless.

@timothyarmes Unfortunately, you can't do await on componentWillMount or any other life cycle methods. So as @nmaro pointed out, it's rather the problem with react. I think it's hard to solve the issue unless React changed the behavior.

Can we still explore using a store such as Redux as react-resolver does (https://github.com/zeit/next.js/issues/192#issuecomment-258569735)?
I'd love to have @arunoda's opinion, considering your interest in GraphQL. IMHO we need to properly solve this, otherwise Next won't be able to scale for all projects with data-connected components.

How about @VanCoding's solution in https://github.com/facebook/react/issues/1739#issuecomment-267032331? See code.

This issue seems trickier than it sounded. I'm curious about the developments around this, especially on the react side, but I believe that for the time being I'm going to settle for this pattern:

load the main expected data in the root getInitialProps for ssr
and then secondary data only client-side

@nkzawa what happens if you try? Surely it should just look like a long synchronous call as far as React is concerned.

@timothyarmes using await in componentWillMount will cause it to return a Promise. React will not wait for the promise to resolve.

Yeah, I wasn't thinking clearly. To use an await the function has to be declared async, and clearly we can't do that.

Made a simple repo with a solution to this issue:
https://github.com/reel/nextjs-initialprops-back

@reel seems like you're still re-calling getInitialProps manually from the parent, so that doesn't solve the described issue.
I'm waiting for feedback from @nkzawa in #387, that's the best hope so far.

Well, in the example, the parent does not handle the state. What I'm trying to achieve is bootstrap some stuff in the Application (in another project) and let the child handle data fetching (and injection with feathersjs)

@nkzawa this issue now seems to be fixed! My need was for Apollo components and as pointed out by @ads1018 in https://github.com/zeit/next.js/issues/387#issuecomment-271089470, everything can be set up from the component root so that deeper components don't need any getInitialProps 🎉. This might be closed I think.
I updated my app: https://github.com/RelateNow/relate

From this week's React Conf, after React Fiber (React 16) is out:

Means async React lifecycle methods could be coming?
https://github.com/facebook/react/issues/1739#issuecomment-287066224


is this library still being maintained?

Description
Please provide some context about the problem and some code examples if relevant.
The best way to provide an example is repository or use Code Sandbox(there is a prepared template for Code Sandbox)

Yep!  Is there anything we can help you with?

Just checking out if it's still reliable to use 😉. Thank tou @neurosnap

No worries!

The saga library will go on working fine, being maintained. Well, it's a great  news! Redux-Saga is a masterpiece!