2.0 Release planning

With #91 and #98 merged, we can start to think about when we want to press release on 2.0
Changes since 1.0.2:

Fix: Const correctness in C api in https://github.com/roualdes/bridgestan/pull/89
Send Stan outputs to stdout rather than stderr in https://github.com/roualdes/bridgestan/pull/94
Allow Stan outputs to be redirected to higher-level things like Python's sys.stdout in  #108
Expose version numbers in C API in https://github.com/roualdes/bridgestan/pull/101
Breaking change: Propagate error messages through C API in https://github.com/roualdes/bridgestan/pull/91
Allow nullptr as data argument to constructor in https://github.com/roualdes/bridgestan/pull/104
Breaking change: Implement param_constrain in a thread-safe way in https://github.com/roualdes/bridgestan/pull/98
Updated Stan to 2.32.0 in (#109)

Further changes coming at some point (non-breaking, could be 2.1 if we don't want to wait):

Rust interface #105 (timeline TBD)

Thoughts @roualdes @bob-carpenter? I'm in favor of releasing 2.0 soon (maybe Monday?), and then when #105 is ready that would be 2.1 later on

There was some discussion in #105 about adding functions to parse variable names.  If we added such functions to all interfaces, do you imagine that would be a minor version bump after releasing 2.0?

Yes, it should be possible to add those in a way which is entirely backwards-compatible. I'm hesitant to attempt them before tuples (which I am pushing for in the next Stan version), both because so much will change and because it's possible new features in the generated code would make it easier.

Sounds good.  I'm in favor of releasing 2.0 too.

If we work around the library unloading issue in #105, I think I can get this ready for review on Monday. So if you want to get it into 2.0 as well, I guess that wouldn't delay things all that much, assuming there aren't any other major issues.

I'd personally rather do a 2.1 for that, if only because it lets us take our time for review and keeps the release notes more focused.
Speaking of, here's my proposal for release notes:

BridgeStan 2.0.0
This version of BridgeStan features several breaking changes, primarily to the C API which is used "under the hood", but also to how models with generated quantities must be called. Additionally, many "quality of life" features have been added, ranging from const correctness in the C API, to vastly improved error messages in the interfaces.
The BridgeStan documentation has been updated, and old versions of the docs are now available via a dropdown at the top of each page.
Interface changes
Breaking Changes

For all interfaces, the param_constrain family of functions now accept an rng argument of type StanRNG. This is required if include_gq is set in the function, otherwise it may be omitted. These RNGs are now used in any RNG function calls inside the generated quantities block, rather than using an RNG stored inside the BridgeStan model object.
This means that the param_constrain function is now thread-safe if each thread has its own StanRNG. See the documentation for your preferred interface for more on how to instantiate StanRNGs.

Other Changes

BridgeStan has updated to Stan 2.32
Error messages are now properly reported by each language's preferred exception mechanism. This means no more "See C++ stderr for details" messages when an error occurs.
All interfaces: print() statements inside of Stan models will now be directed to stdout instead of stderr.
Python: print() statements inside of Stan models are re-directed to sys.stdout by default to allow them to appear in things like Jupyter notebooks. See the capture_stan_prints argument to the StanModel constructor for more details.

C API
Breaking Changes

Mirroring the above changes for param_constrain, the bs_model_rng type has been split into two types, bs_model and bs_rng. The creation and destruction functions have been renamed to bs_model_construct/bs_rng_construct and bs_model_destruct/bs_rng_desctruct.
The param_constrain function accepts a new bs_rng* argument, which can be NULL if include_gq is false.
Any function in the C API which can fail (those which return integer return codes) now accept an additional argument of type char **. If a non-null pointer is provided, it will be set to a newly allocated error message string if a failure occurs. Error messages are no longer printed to stderr. These strings must later be freed by calling a new function bs_free_error_msg.

Other Changes

The C API functions now properly mark bs_model* arguments as const where appropriate. With the param_constrain changes, this means all functions except for bs_model_destruct take a const pointer now.
Three new constants are available in the C API - bs_major_version, bs_minor_version, bs_patch_version.
The data argument to the bs_model_construct function can now be NULL, indicating "no data".
A new function, bs_set_print_callback is available. This can be used to provide a function which is called when print statements in the Stan model are run. This is primarily used in the Python interface to re-direct to sys.stdout.

We're going to hold off for Stan 2.32.1 which will fix a build issue and improve a couple error messages (which would be relevant to bridgestan users in bs_param_unconstrain_json)
The above release notes will still be correct aside from the .1 in the vendored Stan version


fiobj_hash_pop quick fix

Hello,
it seems to me that the implementation of fiobj_hash_pop broke accidentally during this commit, where the negation was removed.
Currently pop never returns anything because this line:
if (fio_hash___count(&obj2hash(hash)->hash)) FIOBJ_INVALID;
returns FIOBJ_INVALID if the hash does contain items.
This seems wrong to me, I think it should be:
if (!fio_hash___count(&obj2hash(hash)->hash)) FIOBJ_INVALID;
With the negation reinstated the pop function would work again as we need it to.
Since this is such a tiny change it would probably be best if someone with appropriate rights to the project just quickly pushed the fix :)

Hi,
Thank you for this quick catch.
I've been busy with developing the facil.io 0.8.0 upcoming version for too long and hadn't had much time to look back.
I actually deprecated for feature in the upcoming 0.8.0 (dev) release, as it makes too many assumptions about the underlying structure of the Hash table (mainly, the assumption that ordering is preserved)..
For implementing caching and ordered maps, version 0.8.0 will offer other solutions (such as Hash maps ordered by either insertion or Least-Recently-Used key-value pairs, along with auto/manual eviction.
Is Hash.pop a useful feature for you? Could you tell me what your use-case may be?
Thanks,
B.

Hi,
thats totally understandable.
I was using the feature to pop all elements of the map into an array, processing the array and then putting them back into the map again.. which is not the way to do it, I know that.
I found the loss of control through the fiobj_each uncomfortable for my use case, so I worked around it.
Will there be some way to iterate arrays and hash tables, without giving away control? E.g. by some kind of iterator (handle)? This also saves a lot of hassle when just quickly iterating through all items of a collection.
I haven't looked at 0.8 yet, so if this already possible then don't mind my misuse of the current functions :D
Thanks for the quick answer,
Urs

Hi Urs,
Thanks for getting back to me!
Hmmm... yes, I have your use-case covered (with the FIO_MAP_EACH macro which basically uses an iterator fiobj_hash_get_next). It should also work for the FIOBJ Hash Map (though I still need to rewrite a lot of the docs for that module).
Funny enough, the reason I wanted to deprecate the fiobj_hash_pop function is because in your version (0.7.x) the map is implemented using an Array (in order of insertion) with an index map (similar to the iMap implementation here).
If you dig a little into the map storage in your implementation, you can use the array directly and avoid the overhead.
In the new version there's no array, which improves performance for random access (though looping is adversely affected).
If you will want an Array-Map combo, I suggest you define an iMap for your specific data type (or for FIOBJ). Maybe have a look at the FIO_TYPEDEF_IMAP_ARRAY macro) and its documentation.
Good luck,
B.

Sure, good luck!
FYI, I incorporated the Fix.


Eagle 119 fixunittest

Siddhi does not support external time based snapshot yet, need cancel this unit test

only need include unit test fix


Current Development and contributions

I saw some other questions over the last few months about the status of this project but I haven't seen any recent activity. Is this project currently under development? And is there anything I can do to help you get this out?

Yeah me too.

@ugiacoman

@gwenf @vaibhawc @pgarciacamou Hey guys, sorry for the lack of updates. I haven't been able to give this project the attention it deserves. If anyone wants to take it up, by all means!

@ugiacoman you can transfer it to me. I'm going to be working with react-native a lot more in the next few weeks and would love to work on this 👍

I know there is a lot of people waiting for this, I haven't had time to start it just yet, but I have to soon.

@pgarciacamou love it :)

I will close this for now.
In the upcoming weeks I'll design a potential API. In the following months I'll start implementing it -
iOS first. It is too early to predict a potential alpha release though.


BUG: directed_hausdorff subset fix

Fixes #11332

directed_hausdorff now correctly handles
cases where one of the vectors is a subset
of the other

Given that this is a single-character bug fix with CI all green, no old tests modified (only new tests added), and there aren't too many active reviewers for this corner of spatial I'll go ahead & merge.
This is really the fix from @anamamatelashvili, so thanks!


Please add the following companies

IHS Markit
PeopleStrong
GoDigit
LogicFruit
314e Corporation
Cvent

Sure, I've assigned it to you!


Release 2.2.0

Issues
Test evidence

+1 for release

+1 for release.

Released,

https://github.com/cerner/cerner_tomcat/tree/v2.2.0
https://supermarket.chef.io/cookbooks/cerner_tomcat/versions/2.2.0


Bugfix: Use prod YAML without dev flag

Hi, just a wee lil bug here.

Thanks for catching that and submitting a PR, @jenic!


Fix/readme

This PR

[x] adds the doctrine config to development.local.php.dist
helps creating the db in local environments easier
[x] removes the old data/sql information in the readme
[x] adds additional information for Github Login in local environments
[x] removes the old vagrant information
[x] adds information how to build the database with doctrine migrations

:+1:

:+1:

thanks @Ocramius @gianarb


DoS vector in protocol message stream

I haven't tested this, but I reckon there is DoS vector in the protocol message stream that attackers can exploit without breaking our crypto.
The weave TCP protocol is a gob stream of messages: a map[string][string] for the first message, the handshake, followed by []byte messages. The latter are all encrypted when crypto is enabled. Note that it's the individual messages that are encrypted, not the stream. And the first message - the handshake - is always unencrypted.
It is therefore possible for an attacker to exploit weaknesses in gob. The following spring to mind:

triggering an OOM crash by sending a very large gob message
triggering an OOM crash by sending a sequence of octets that triggers a large memory allocation in gob
triggering a loop in the gob decoder

I am quite sure 1 is possible. There is a 1GB limit in place but a) that's still quite large, and b) doesn't apply everywhere.
2 is different from 1 because it does not require network capacity and is therefore impossible to guard against with firewalls that enforce capacity limits. And I think it is possible, based on my reading of the gob decoder, i.e. there are places where a capacity is read and then an allocation of that capacity is performed.
I don't think 3 is possible, based on the description of gob. But I could well be wrong.

When you say "very large gob message", does the receiver accept messages with any length? I guess there should be a reasonable upper limit...

see my analysis above re length. The only limit I can find is 1GB, and it does not apply everywhere.

You analysis talks about the gob limits, but what I mean is whether we check the message length before passing it to the gob decoder... I think it does not make sense to try to decode any message (specially if we want protocol upgradeability)

There is no such thing as "messages" before the gob decoder. The gob layer is what gives us our message framing.

Oh, I see, so we are in the hands of gob...

Oh, I see, so we are in the hands of gob...

Nice :)
It strikes me that either

The maximum buffer size in gob should be adjustable (drastically, downwards); or,
gob is a poor choice for the purpose to which weave puts it.

Wire-encodings of messages is limited to 1GB, but by using specific structs you can create a gob stream where:
Encoded:     15 MB
Allocated: 1931 MB

Not yet sure if it is exploitable in weave.

Is that using straight gob or did it involve injecting byte sequences that "look like gob"? It's the latter that I suspect might permit allocating arbitrary large amounts of memory from little input. Not sure though; very much depends on the structure and implementation of the gob codec.

regular gob.

slices have their size checked before decoding, but structs don't.

Related: https://github.com/golang/go/issues/10490


Please add namespace 'tech.mastersam.livechat'

Please add namespace 'tech.mastersam.livechat'

Hi @ProFive
What version of the plugin are you using?

Sorry 1.5.1
Thanks & best regards,
Nani
Mobile: +84.935.357.567
Skype:ngvannam55
On Wed, 6 Nov 2024 at 17:39 Nguyễn Văn Năm @.***> wrote:

I used the version 5.1.0
Thanks & best regards,
Nani
Mobile: +84.935.357.567
Skype:ngvannam55
On Wed, 6 Nov 2024 at 17:27 Samuel Abada @.***> wrote:

Hi @ProFive https://github.com/ProFive
What version of the plugin are you using?
—
Reply to this email directly, view it on GitHub
https://github.com/Mastersam07/livechat/issues/40#issuecomment-2459258403,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABHOLOBAIHX6LPRPARQLV4TZ7HVHPAVCNFSM6AAAAABRIPOZCCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINJZGI2TQNBQGM
.
You are receiving this because you were mentioned.Message ID:
@.***>


Looking for maintainers

I am stepping down from maintaining this repository as the functionality will be part of https://github.com/the-codegen-project/cli
If anyone wants to take over the maintenance efforts of the template just write a comment under here. Otherwise, this repository will be archived within 2 weeks.
cc @derberg

Hello there! I saw you're searching for someone to maintain this template repository, and I'd like to take it on. I'm experienced with JavaScript and TypeScript, and as an OpenSource maintainer, I believe I can keep the template up to date and running smoothly.


Integration with Giraffe

What's the proper way to integrate with Giraffe? (or implement the IJsonSerializer)
https://github.com/giraffe-fsharp/Giraffe/blob/master/DOCUMENTATION.md#serialization

Hi @codingedgar . This would be a great idea. I quickly took a look at IJsonSerializer I think it should be fairly easy to implement it with API provided by FSharp.Json.
This https://github.com/giraffe-fsharp/Giraffe/blob/8a4300e6e8fc6fac2119da044073ba8e2bf22940/src/Giraffe/Serialization.fs#L73-L115 looks pretty trivial.
I'm not sure if I will be providing library with such implementation myself. I soon will need to take a look at F# with Giraffe and will decide it then.

I just came here to ask the same thing. I just finished writing it (though I don't have tests for it yet); would this be something you'd be interested in for this project, or should I package it up myself?
BTW, here's my implementation.
  open FSharp.Control.Tasks.V2.ContextInsensitive
  open FSharp.Json
  open Giraffe.Serialization
  open System
  open System.IO
  open System.Text
  open System.Threading.Tasks

  /// A serializer implementation using FSharp.Json's serialization functions
  type FSharpJsonSerializer () =
    interface IJsonSerializer with
      member __.SerializeToString<'T> (x : 'T) =
        Json.serialize x
      member __.SerializeToBytes<'T> (x : 'T) =
        (Json.serialize >> Encoding.UTF8.GetBytes) x
      member this.SerializeToStreamAsync<'T> (x : 'T) (stream : Stream) =
        task {
          do! stream.WriteAsync (ReadOnlyMemory ((this :> IJsonSerializer).SerializeToBytes x))
          } :> Task

      member __.Deserialize<'T> (json : string) =
        Json.deserialize<'T> json
      member this.Deserialize<'T> (bytes : byte array) =
        Encoding.UTF8.GetString bytes |> (this :> IJsonSerializer).Deserialize<'T>
      member this.DeserializeAsync<'T> (stream : Stream) =
        task {
          let! bytes =
            match stream.CanSeek with
            | true ->
                task {
                  let bytes = Array.create (int stream.Length) (byte 0)
                  let! _    = stream.ReadAsync (Memory bytes)
                  return bytes
                }
            | false ->
                task {
                  let mutable recv : byte[] list = []
                  let mutable moreBytes = true
                  let rdr = new BufferedStream(stream)
                  let buf = Array.create 1024 (byte 0)
                  while (moreBytes) do
                    match! rdr.ReadAsync (buf, 0, 1024) with
                    | 0 -> moreBytes <- false
                    | byteCount ->
                        recv      <- (Array.chunkBySize byteCount buf).[0] :: recv
                        moreBytes <- byteCount = 1024
                  return List.foldBack (fun recvBytes allBytes -> Array.concat [ allBytes; recvBytes ]) recv [||]
                  }
          return (this :> IJsonSerializer).Deserialize<'T> bytes
        }

Just looked at the Giraffe implementation; it looks a bit cleaner than mine. (I'm not sure that I've thrown > 1,024 bytes at it yet.)

@danieljsummers I can package it and publish it as FSharp.Json.Giraffe (I have booked the package name already). I will check code and put it into FSharp.Json.Giraffe soon.


Socket connection issue after heroku deployment

When I deploy my website to heroku app everytime it is connecting to new port
In the client code, we are adding static port
const SERVER_URL = 'http://localhost:8080';
public initSocket(): void {
this.socket = socketIo(SERVER_URL);
}
Therefore, after deploying the website on heroku, socket is not working.
Could you please tell me how you made it possible on heroku deployment.
Is it due to I am using free service of heroku (may be). I dont know the reason.
Thanking you in advance.

@luixaviles can you open a wiki page so that we can add deployment notes for each platform like heroku and zeit?
Then I could add my notes to it:
I've successfully deploy to zeit separating the client and the server. Here are my steps:

first I attempted to deploy the server

cd server
now

No problems... so after a successful deploy... I did:
now alias https://socket-io-typescript-example-aknmfgiriy.now.sh mapdrops-api

I have a side project called mapdrops about analyzing run data and learning Angular 5. I used the alias 'mapdrops-api' to mark it as my API.

update the client to point to this new remote url https://mapdrops-api.now.sh instead of localhost:8080 and use the environment files as configuration.

export const environment = {
  production: true,
  url: 'https://mapdrops-api.now.sh'
};

Find src > app > chat > shared > services > socket.service.ts
import { environment } from '../../../../environments/environment';
import * as socketIo from 'socket.io-client';

//const SERVER_URL = 'http://localhost:8080';
const SERVER_URL = environment.url;

I ran client locally and it connected to the remote url so I felt confident to deploy it
now

After a successful deploy... I did the alias
now https://typescript-chat-client-djuavnsujl.now.sh mapdrops

This time, when I checked the url https://mapdrops.now.sh in the browser I got:
Invalid host header
I encountered this problem yesterday and, while I don't have a perfect fix for it yet, this does work:
Edit package.json
"start": "ng serve --disable-host-check",

If anyone has a better solution here, I'd like to hear it ;-D
I deployed it again, did the alias, and both the client and server are talking to each other now:
working demo

@luixaviles awesome - I've moved the zeit notes over to it and stubbed in a heroku section for @gibbsvjy007 to complete ;-D

Just added a reference to Readme file with the notes added by @headwinds. Thanks a lot for your contribution.


OCM-141: Terraform for IMDSv2 support

    Adding support for http_tokens_state field. This field can be used only
    from 4.11.0 and have 2 options: optional/required

@tsorya why closing it?

will reopen, some github issue on my side


GLTF2Loader is out of date

I tried using the current npm package and it fails on the RiggedFigure sample from here:
https://github.com/KhronosGroup/glTF-Sample-Models/tree/master/2.0/RiggedFigure
I manually copied the updated GLTF2Loader code from three.js and it now supports that scene.  Issue was a change/deprecation to the skinWeight attribute (WEIGHTS_0).
i see you already have a dev branch with newer gltf2loader so it would be great to publish that on npm!

Hi @nfurtwangler
Thanks for pointing this out, please refer to the latest version published at NPM (v1.1.0)
https://github.com/antonio-gomez/three-gltf2-loader/releases/tag/1.1.0


How to Start Yaws

Hi,
I have used following commands :-

apt-get install yaws
yaws
(it gives error).
=INFO REPORT==== 16-May-2017::14:12:33 ===
Yaws: Using config file /etc/yaws/yaws.conf

=INFO REPORT==== 16-May-2017::14:12:33 ===
Yaws: Using global subconfig file /etc/yaws/conf.d/localhost-ssl.conf
=INFO REPORT==== 16-May-2017::14:12:33 ===
Warning, Skip invalid docroots at line 17 : /usr/share/yaws/www
=ERROR REPORT==== 16-May-2017::14:12:33 ===
Yaws: bad conf: No valid docroot configured for virthost 'localhost' (port: 8443) terminating
How to fix it ? Can anyone help?

Try creating a file with the following content and name the file "yaws.conf":
id = "Test"

<server localhost>
    listen = <IP_ADDRESS>
    port = 8443
    docroot = .
</server>

Then execute:
$yaws --conf yaws.conf
Note that you need a valid "docroot" field in the configuration. In the example above, the current directory is used as the docroot.

Thank you
It worked...

Cheers.


Allow seeing STI logs when doing integration tests

Currently adding -v flag to hack/test-integration.sh shows only the logs from the integration tests itself. Whereas when searching for test error I'd like also to see STI internal which you turn on with --loglevel=3.

@gabemontero note that this is in the source-to-image repo, not origin.

Based on some chatter in #openshift-brno, this item could also encompass creating a debug guide for STI.

pull 233 delivered the code changes which have been merged into openshift:master, but leaving this open to address the debug guide for STI.
I've solicited (and already received some) feedback on what could feed into a debug guide.  I'll paste that initial feedback here once it seems to have stabilized, and start writing from there.

The feedback I received regarding an STI debug guide:
From Maciej:
I suggest you have a look at our pkg/errors/errors.go where we've put
'suggestions' to certain errors. Those contain some hints which could
be a good starting point for such guide. Additionally when you'll be
going further down the road don't hesitate to add/change that parts
and update the suggestions or even adding additional errors to make
the output even more clearer. You could also check out some issues
and see if you could get some common errors people had with s2i.
I hope that helps,
Maciej
From Ben:
yeah looking at the closed issues on the source-to-image repo is a great idea.

Don't forget about your initial experience with s2i, all the questions and doubts you were having when doing your first s2i build :wink:

@soltysh Absolutely ;-) .... though I will say that so far my questions/doubts have not been with the mechanics of using s2i (i.e. items for a debug guide) but more the higher level concepts in the README.md.  Now, some of that most certainly stems from my inexperience with Docker / OpenShift in general.  But as I'm going through this, I'm wondering if some dialogue not just of the s2i process, but how the output produced from running s2i ties in with what customer then do when say manipulating their templates or running oc new-app.  Not sure if I'm ready to articulate that yet (at least not without editing and review for sure), but that could be another thread on this work.

Here is the PR for the debug guide doc changes:  https://github.com/openshift/source-to-image/pull/242


eval.py Error [ ValueError: not enough values to unpack (expected 2, got 0) ]

../ssd.pytorch/layers/functions/detection.py", line 54, in forward
ids, count = nms(boxes, scores, self.nms_thresh, self.top_k)
ValueError: not enough values to unpack (expected 2, got 0)
What does that mean?
How to solve that problem?

reference : https://github.com/amdegroot/ssd.pytorch/issues/154
I changed the code as follows and worked for me.

@MakeToast, i tried your solution reference #154 but the following error is being displayed for every frame and the detection is not up to the mark. I couldn't understand this, could you explain please.
..\torch\csrc\autograd\python_function.cpp:622: UserWarning: Legacy autograd function with non-static forward method is deprecated and will be removed in 1.3. Please use new-style autograd function with static forward method. (Example: https://pytorch.org/docs/stable/autograd.html#torch.autograd.Function) ..\torch\csrc\autograd\python_function.cpp:648: UserWarning: Legacy autograd function object was called twice. You will probably get incorrect gradients from this computation, as the saved tensors from the second invocation will clobber the saved tensors from the first invocation. Please consider rewriting your autograd function in the modern style; for information on the new format, please see: https://pytorch.org/docs/stable/notes/extending.html#extending-torch-autograd


README.md file are added with pictures and other related things

Hey @Anushkabh ,
I have done my work on the documentation issue #46. I hope you will love the work. If anything is mistaken, ping me, and I will change it accordingly....And with the help of you I have made my first contribution..
Thank you..
And kindly label this issue as 'gssoc' also...

Hello @Yashpreeth, I'd like to suggest an update to the readme file you recently uploaded. The screenshots included are not seamless; there are noticeable breaks. I can provide cleaner images, similar to the ones I've attached, which would greatly improve the page's appearance.

@Anushkabh Sure

Fixes #46


RFC: Function Idempotency Helper

Key information

RFC PR: (leave this empty)
Related issue(s), if known:
Area: Utilities
Meet tenets: Yes

Summary
Helper to facilitate writing Idempotent Lambda functions.
The developer would specify (via JMESPath) which value from the event will be used as a unique execution identifier, then this helper would search a persistence layer (e.g. DynamoDB) for that ID; if present, get the return value and skip the function execution, otherwise run the function normally and persist the return value + execution ID.
Motivation
Idempotency is a very useful design characteristic of any system. It enables the seamless separation of successful and failed executions, and is particularly useful in Lambdas used by AWS Step Functions. It is also a design principle on the AWS Well Architected Framework - Serverless Lens
Broader description of this idea can be found here
Proposal
Define a Python Decorator @idempotent which would receive as arguments a) the JMESPath of the event key to use as execution ID, b) {optional} storage backend configuration, e.g. DynamoDB table name, or ElasticSearch URL + Index).
This decorator would wrap the function execution in the following way (pseudo-python):
from aws_lambda_powertools.itempotent import PersistenceLayer

def idempotent(func, event_key, persistence_config):
  def wrapper(*args, **kwargs):
    persistence = PersistenceLayer(persistence_config)
    key = jmespath.find(event_key, **kwargs['event'])
    persistence.find(key)

    if persistence.executed_successfully():
      return persistence.result()

    try:
      result = func(*args, **kwargs)
      persistence.save_success(key, result)
      return result
    except Exception => e:
      persistence.save_error(key, e)

  return wrapper

Usage then would be similar to:
from aws_lambda_powertools.itempotent import itempotent

@idempotent(event_key='Event.UniqueId', persistence_config='dynamodb://lambda-idemp-table')
def handler(event, context):
  # Normal function code here
  return {'result': 'OK', 'message': 'working'}

The decorator would first extract the unique execution ID from the Lambda event using the JMESPath provided, then check the persistence layer for a previous successfull execution of the function and - if found - get the previous returned value, de-serialize it (using base64 or something else) and return it instead; otherwise, execute the function handler normally, catch the returned object, serialize + persist it and finally return.
The Persistence layer could be implemented initially with DynamoDB, and either require the DDB table to exist before running the function, or create it during the first execution. It should be in such way as to allow different backends in the future (e.g. Redis for VPC-enabled lambdas).
Drawbacks
This solution could have noticeable performance impacts on the execution of Lambda functions. Every execution would require at at least 1, at most 2 accesses to the persistence layer.
No additional dependencies are required - DynamoDB access is provided by boto3, object serialisation can use Python's native base64encode/decode
Rationale and alternatives

What other designs have been considered? Why not them?
No other designs considered at the moment. Open to suggestions.

What is the impact of not doing this?
Implemention of idempotent Lambda functions will have to be done 'manually' in every function.

Unresolved questions

How to make the persistence layer access as fast as possible?
Which other persistence layers to consider (DynamoDB, ElasticSearch, Redis, MySQL)?

Some comments:

We should handle duplicate calls, and short circuit with a in progress error. (This would mean one additional write to create the initial lock and a second right when the task has been completed). For Dynamodb could use conditional conditional expression to “insert or get” the saved request
We should allow for composite keys. Like an request id and the authenticated user id (like a cognito sub). This would prevent users from accessing other event results.
Could we leverage Lambda extensions to offload the saving of the result to dynamodb?
There should be an optional TTL on these records, for example we cache the result for up to 24 hours.
In same cases what we store in dynamodb might be sensitive. So an optional flag for field level encryption would help
We might also want to validate if the same idempotent key has been used for different request parameters. This would prevent misuse of this feature by the end user. Either the end user is not generating a unique key or are reusing the same key for a different request. To support this we would also optional store the request parameters.

Sorry one more thing to consider.
When there is an error, sometimes we might want to allow for retrying by the same idempotent key. For example, the lambda is calling some downstream service that is temporarily unavailable, calling with the same idempotent could make another downstream request. In this case we would want to remove any lock record that might have been created.
However if the end user is passes in an invalid request we should return a 400 type of response and potentially not do a round trip to the persistence layer. This will prevent bad requests from taking up any additional bandwidth.
Otherwise, we could fall back to an in memory local fifo cache to serve back just the most recent retries.
I feel like if we can some how offload the dynamodb writes to an async task, then we can optimize for the common case of the first request going through.
And we should also consider using metric or annotations to track cache hits, so that the developer can see how useful this feature really is.
This feature is particularly useful for financial transaction that can take some time to process and you don’t want to double charge the end user.

Couple features we could pair with this is an idempotent queue. There we want to do some validation and checks, before putting on one request into the dynamodb or some other queue. Idempotent keys would prevent double submits, and the heavier processing can be handled by another process or lambda. Having the lock record at the beginning of the request can work as well for when our lambda execution can run much longer than the request timeout of the caller.
As a separate RFC we could have a nonce feature, which is similar to this, but instead we return a single use token. (But that is for another occasion 😄 )

Great comments, @michaelbrewer ! Some inline replies.

We should handle duplicate calls, and short circuit with a in progress error. (This would mean one additional write to create the initial lock and a second right when the task has been completed). For Dynamodb could use conditional conditional expression to “insert or get” the saved request

Yes! I'll amend the flow description, it should be something like "Start -> Extract Key -> Check in DB if running or completed -> If running, return 'BUSY'; if complete, return saved result; else Insert 'RUNNING' -> Continue"

We should allow for composite keys. Like an request id and the authenticated user id (like a cognito sub). This would prevent users from accessing other event results.

In general terms, the developer needs to provide a uniquely identifiable value for each execution. If that requires a composite key, by all means. I only worry about the complexity of this implementation for v0.1

Could we leverage Lambda extensions to offload the saving of the result to dynamodb?

There should be an optional TTL on these records, for example we cache the result for up to 24 hours.

Agree 100%. This factors in the table design, particularly if we allow the solution to 'create table if not exists'

In same cases what we store in dynamodb might be sensitive. So an optional flag for field level encryption would help

Agree 100% as well. Optional config flag to KMS encrypt fields. Worth mentioning the (possible) additional cost and time in the docs.

We might also want to validate if the same idempotent key has been used for different request parameters. This would prevent misuse of this feature by the end user. Either the end user is not generating a unique key or are reusing the same key for a different request. To support this we would also optional store the request parameters.

Not sure I follow. The only requirement for the idempotence key is that it uniquely identifies each execution. If requests are made with different parameters, they should have different idemp. keys...

When there is an error, sometimes we might want to allow for retrying by the same idempotent key. For example, the lambda is calling some downstream service that is temporarily unavailable, calling with the same idempotent could make another downstream request. In this case we would want to remove any lock record that might have been created.

Yes. Few options here. If the function throws an Exception, we can:

a) Record that information in the DB (e.g. key=xyz, status=FAILED) and then, on the next execution w/ key=xyz, we know to continue running, or
b) Delete the record w/ key=xyz, so next time it'll be like a first execution, or
c) Expose a few exception types that dictate the behaviour for next executions (retry or not).

However if the end user is passes in an invalid request we should return a 400 type of response and potentially not do a round trip to the persistence layer. This will prevent bad requests from taking up any additional bandwidth.

Absolutely, best to catch invalid requests as early as possible.

@igorlg - i agree that some of this feedback is based on more advanced use cases.
Use case:
Lambda is part of an api gateway function used by external developers (or internal developers but on a different team). So we would want to protect against usage errors. Like reusing idempotent keys for different requests. For V0.01 we could just document that the request id has to be server generated using UUID. And retries should be for the exactly same request.
Use case:
Lambda can be called via a Appsync resolver or Api gateway directly. So to help prevent a bad user reading a cached response for another user, a compound key taking the user inputted fields along with authenticated fields. (Again we could defer this to the documentation).
Another interesting feature when pairing this with the API gateway would be to return a header parameter like Idempotent-Replayed: true to signify whether the response was a cache hit or a replay.
Stripe has a pretty good implementation of idempotency - https://stripe.com/docs/idempotency

all great comments - my suggestion is to expand the RFC @igorlg to expand on:

Responding to duplicate requests (e.g. callback function like batch utility, return last response cached, depending on event source respond X)
Responding to exceptions (e.g. clear cache, retry/do-not-retry)
Standalone function for more control over failure mode
Persistence layer should follow the Parameters implementation of Bring Your Own - Implement one, DynamoDB, and leave others for post-launch
Separate what's must have vs nice to have
Sequence diagram or text (step->step) to quickly visualize steps
Don't worry about naming of the parameters or pseudo code - We can handle UX later after we get down to the must haves

As to comments by @michaelbrewer on sensitive fields, composite keys, Extensions and metrics, here's my initial take on:

Sensitive fields and Extensions - Customers can customize their persistent layer on inserting and querying the data. In the case of Extensions, they can query filesystem, use IPC, etc.
Composite keys - JMESPath allows for multiselect. If the return from the query selection is a Sequence or a Dict, we can serialize it and encode/hash it
Metrics - If we support a callback fn (e.g. idempotency_handler()), customers can use Metrics utility or their own mechanism to track that. We'd call this function when the request is idempotent and when using the decorator, so they'd have full control over the logic, how the response should be returned given their event source (e.g. API GW vs SFN)

@heitorlessa  should we allow for an in-memory LRU cache?
Also for the in-progress errors, we might want a overall timeout (or permanent failure), but we can't always assume the original lambda was able to run to completion, either to memory or lambda timeout.
I think there will be more docs than code for this? And a set of recommendations and warnings about cost.
Stripe wrote a couple good articles, and i am sue their are AWS ones out there too.

@michaelbrewer quite possibly along with a TTL and max LRU cache size - A dict fits the purpose here.
Not entirely sure yet on upon-exception behaviour whether we want to burst the LRU cache and call a provided function e.g. idempotency_handler. That is why my ask to Igor to expand on responding to duplicate events as well as exceptions.
If you have some of those articles or ideas please bring it on ;)

One of the stripe devs has some good articles (somewhat PG related though):
https://brandur.org/idempotency-keys
https://stripe.com/blog/idempotency

@mwarkentin  - yep, those are the articles i was referring to.
I know initially we don’t want to bloat v0.01 of this feature, but i would either flag it as a alpha api with possible breaking changes, or factor in where this could go to in the api design.
For example implementing this feature various based on how it is being integrated. In the context of the API gateway or AppSync we might want to have help functions to return errors, http headers and http error codes etc.

@heitorlessa  maybe we should create a shared repo for RFCs and docs shared by the Typescript/Python and Java implementations, so we keep the design in sync and help other maintainers to support the implementation up to date.

@heitorlessa  @nmoutschen should we collate these requirements and start on a prototype implementation?

Sorry folks I'm unwell but this is being taken care of -- cc @cakepietoast to provide an answer
I'll reply to the shared RFC repo as soon as I'm recovered

Get better soon @heitorlessa! I'm working with @igorlg on this, we expect to have at least the starting point of an implementation added to the repo in the next week or so based on this RFC.

@igorlg @mwarkentin @michaelbrewer @heitorlessa curious to hear your thoughts on how you think exception handling should work. Given a lambda is invoked and raises an exception, should we:

Ignore it completely in the idempotency logic, meaning the lambda code will not be "protected" from retries which cause an unhandled exception. This simplifies the code, and will apply idempotency logic only for succesfully completed lambda executions.
Pickle the exception and store it in the idempotency store. For the next execution with a matching idempotency key, we can unpickle and return the exact same exception.
Find an alternative to pickle to serialize and deserialize the exception. I'm having a hard time thinking of a good solution for this that doesn't have the same security consequences as pickle. It would likely require either a third party lib or some relatively complex code to implement.
Store a serialized representation of the exception. For the next execution with a matching idempotency key, return a generic exception with some details from the originally thrown exception. This will complicate error handling for the caller and wouldn't be truly idempotent as the response would not be the same as the original invocation.
Something else entirely!

The current prototype implementation uses a combination of 1 and 2. We provide an option where a user can pass a list of exception classes that are not "retryable". Any subclass of those will then be pickled and stored as per 2. I'd rather avoid use of pickle here for security reasons, but getting rid of it involves some tradeoffs (points 1, 3 or 4). Personally I'm leaning towards 1, but want to get feedback from others before making any changes there.

@igorlg @mwarkentin @michaelbrewer @heitorlessa curious to hear your thoughts on how you think exception handling should work. Given a lambda is invoked and raises an exception, should we:

Ignore it completely in the idempotency logic, meaning the lambda code will not be "protected" from retries which cause an unhandled exception. This simplifies the code, and will apply idempotency logic only for succesfully completed lambda executions.
Pickle the exception and store it in the idempotency store. For the next execution with a matching idempotency key, we can unpickle and return the exact same exception.
Find an alternative to pickle to serialize and deserialize the exception. I'm having a hard time thinking of a good solution for this that doesn't have the same security consequences as pickle. It would likely require either a third party lib or some relatively complex code to implement.
Store a serialized representation of the exception. For the next execution with a matching idempotency key, return a generic exception with some details from the originally thrown exception. This will complicate error handling for the caller and wouldn't be truly idempotent as the response would not be the same as the original invocation.
Something else entirely!

The current prototype implementation uses a combination of 1 and 2. We provide an option where a user can pass a list of exception classes that are not "retryable". Any subclass of those will then be pickled and stored as per 2. I'd rather avoid use of pickle here for security reasons, but getting rid of it involves some tradeoffs (points 1, 3 or 4). Personally I'm leaning towards 1, but want to get feedback from others before making any changes there.

I think we should seperate errors that are due to bad input (missing a required parameter) vs downstream errors (like failure to write to RDS).

For validation errors we can handle before any of the idempotent checks. And failures will also result in a bad input error of sorts. Retrying will result in the same result, if the client calling the lambda is behaving, would correct the request and retry with a new idempotent key

NOTE: I am assuming where that whenever we first handle a idempotent request, we create an empty locking record, than can later be used to short circuit any retries with an already in progress type of error

For downstream errors we should make this configurable.

REMOVAL - Remove the locking record and return the error. (Then retrying won't return the already in progress error, and if the downstream recovers things continue as normal)
FLAG_IN_ERROR - We update the locking record from in progress to error with a json stringified user error (not, this should be something we can safely persist) and then throw or return the error. Here retries would always fail and even trying with different idempotent key might also fail (if it is a downstream error)

I think we should seperate errors that are due to bad input (missing a required parameter) vs downstream errors (like failure to write to RDS).

For validation errors we can handle before any of the idempotent checks. And failures will also result in a bad input error of sorts. Retrying will result in the same result, if the client calling the lambda is behaving, would correct the request and retry with a new idempotent key

NOTE: I am assuming where that whenever we first handle a idempotent request, we create an empty locking record, than can later be used to short circuit any retries with an already in progress type of error

For downstream errors we should make this configurable.

REMOVAL - Remove the locking record and return the error. (Then retrying won't return the already in progress error, and if the downstream recovers things continue as normal)
FLAG_IN_ERROR - We update the locking record from in progress to error with a json stringified user error (not, this should be something we can safely persist) and then throw or return the error. Here retries would always fail and even trying with different idempotent key might also fail (if it is a downstream error)

@cakepietoast @heitorlessa  I don't mind doing a session on Slack if it is easier to discuss the options.

@cakepietoast @heitorlessa  I don't mind doing a session on Slack if it is easier to discuss the options.

I'd suggest not handling exceptions in the idempotency utility, as you might enter the land of Circuit Breaker here - Which is something we want to work on next.
Caching the exception and returning the same exception would require Pickle to do this cleanly, and yet would create security concerns. It will also not give the opportunity for the function to succeed, as the error might be related to something else (downstream, as Mike said) -- This can get easily convoluted, specially when Lambda might kill the container when it errors out.
This can also make troubleshooting difficult - Try using Circuit Breaker with Idempotency utility in the wrong order, and you won't retries a chance to succeed, including the amount of calls to a persistent store (if Lambda kills the container).
If we're trying to be a good citizen for downstream I'd argue this is the land of Circuit Breaker, not within the idempotency scope.
That said, we'd be happy to discuss this on a call if that needs be

I'd suggest not handling exceptions in the idempotency utility, as you might enter the land of Circuit Breaker here - Which is something we want to work on next.
Caching the exception and returning the same exception would require Pickle to do this cleanly, and yet would create security concerns. It will also not give the opportunity for the function to succeed, as the error might be related to something else (downstream, as Mike said) -- This can get easily convoluted, specially when Lambda might kill the container when it errors out.
This can also make troubleshooting difficult - Try using Circuit Breaker with Idempotency utility in the wrong order, and you won't retries a chance to succeed, including the amount of calls to a persistent store (if Lambda kills the container).
If we're trying to be a good citizen for downstream I'd argue this is the land of Circuit Breaker, not within the idempotency scope.
That said, we'd be happy to discuss this on a call if that needs be

I agree with @michaelbrewer's observations, there should be a clear case for downstream problems and ones caused by bad code in the function.
Any new invoke that happens when because of local issues (bad func code) should be allowed to run as if it was the first time.
Idempotency should be around what happens when there is duplication of the event and how to handle that. One could argue that functions would be considered idempotent if when ran, it didn't change any stored state elsewhere, i.e. when running an insert you don't end up with two rows that look the same.
I'm not sure what could be offered from the powertools projects other than checking for a Message ID and deduping it from something like Redis.

I agree with @michaelbrewer's observations, there should be a clear case for downstream problems and ones caused by bad code in the function.
Any new invoke that happens when because of local issues (bad func code) should be allowed to run as if it was the first time.
Idempotency should be around what happens when there is duplication of the event and how to handle that. One could argue that functions would be considered idempotent if when ran, it didn't change any stored state elsewhere, i.e. when running an insert you don't end up with two rows that look the same.
I'm not sure what could be offered from the powertools projects other than checking for a Message ID and deduping it from something like Redis.

Hi all, I think this is a very interesting RFC but, at first glance, I think there are some important challenges that doesn't seem to be addressed:

In the example above, the time that passes between persistence.find(key) and persistence.save_*(key, result) (including the time spent in the actual processing) allows concurrent lambdas to be invoked for the same event in a different worker that won't know anything about this execution until that time. Without a locking strategy on find I don't think this code is doing what it tries to.
Also, failure to call or execute save_* (i.e. throttling) will allow for non-idempotent executions. Adding a locking mechanism on find may help, but it will add complexity, as it has to handle more calls to the persistence layer and also add  a mechanism for recovery if the execution is aborted somehow, something like a short TTL. This TTL could be managed via Lambda destinations but this would restrict the type of invocations that can be handled making it harder to understand for the user.
Using extensions adds additional complexity as this will create an out-of-process call which may fail or be delayed so the whole purpose of this util will be voided

Hope this helps

Hi all, I think this is a very interesting RFC but, at first glance, I think there are some important challenges that doesn't seem to be addressed:

In the example above, the time that passes between persistence.find(key) and persistence.save_*(key, result) (including the time spent in the actual processing) allows concurrent lambdas to be invoked for the same event in a different worker that won't know anything about this execution until that time. Without a locking strategy on find I don't think this code is doing what it tries to.
Also, failure to call or execute save_* (i.e. throttling) will allow for non-idempotent executions. Adding a locking mechanism on find may help, but it will add complexity, as it has to handle more calls to the persistence layer and also add  a mechanism for recovery if the execution is aborted somehow, something like a short TTL. This TTL could be managed via Lambda destinations but this would restrict the type of invocations that can be handled making it harder to understand for the user.
Using extensions adds additional complexity as this will create an out-of-process call which may fail or be delayed so the whole purpose of this util will be voided

Hope this helps

Thanks for the feedback Pablo! The first two points have been taken into account (and hopefully solved) in the concrete implementation which we're working on in the PR: #245. Your feedback is very welcome on that! For extensions, indeed we'll have issues if someone has an extension which can cause side effects. I don't think that's something we can guard against in the implementation, so I'll make a note to cover it in the documentation.

Thanks for the feedback Pablo! The first two points have been taken into account (and hopefully solved) in the concrete implementation which we're working on in the PR: #245. Your feedback is very welcome on that! For extensions, indeed we'll have issues if someone has an extension which can cause side effects. I don't think that's something we can guard against in the implementation, so I'll make a note to cover it in the documentation.

@cakepietoast Thanks for pointing me to the implementation. My bad for not checking there first.

@cakepietoast Thanks for pointing me to the implementation. My bad for not checking there first.

Just want to capture some additional suggestions I got from @pcolazurdo here:

Add metrics for ItemAlreadyExists, IdempotencyInconsistentStateError, ItemNotFoundError etc. This should be opt-in behaviour.
Different TTLs for successful and in progress (locked) records. If a record is stuck in progress for longer than the lambda timeout period, it indicates that something went wrong processing, and users may want to retry that. However, for successfully completed operations it is more likely that users will want to avoid a duplicate operation for a longer period of time.

Just want to capture some additional suggestions I got from @pcolazurdo here:

Add metrics for ItemAlreadyExists, IdempotencyInconsistentStateError, ItemNotFoundError etc. This should be opt-in behaviour.
Different TTLs for successful and in progress (locked) records. If a record is stuck in progress for longer than the lambda timeout period, it indicates that something went wrong processing, and users may want to retry that. However, for successfully completed operations it is more likely that users will want to avoid a duplicate operation for a longer period of time.

Merged PR #245. Will release in v1.11.0 next week!

This is now available in 1.11.0 - Literally just launched ;) 🎉


Why not choose Aurora Serverless instead of RDS?

It's cool to run the workload on Serverless Fargate, but why not use Aurora Serverless to replace the RDS? so the total solution would be serverless, is that a good idea?

That's a valid point. We too considered adding Aurora Serverless as default offering.
Aurora Serverless is useful when the traffic is low (dev/beta environments) or unpredictable.
For continuous/steady/huge traffic, it will be costlier compared to RDS (reserved  RDS will be much cheaper)
Metadata DB will have regular/continuous traffic in the form of heartbeat and other DAG/Task execution data.
So, we went ahead in favor of RDS (a smaller, free-tier instance)
Being said that, it is easy to swap out RDS with Aurora Serverless.
We have to replace this block of code with something like this
Feel free to submit a PR, maybe a new branch, if you end up using Aurora Serverless instead of RDS.

Thanks @thechaithanya for your suggestion.
I am a solution architecture in AWS from China, since Managed Airflow hasn't been launched in China yet, the solution is extremely important, I'd like to submit a PR to replace RDS using Aurora Serverless, thanks again.

@readybuilderone you should make it an option, to choose aurora or RDS, not eliminate RDS

Yes, I will eventually tackle this as well but its lower down my priority list for this repo


Base coverage collection skipped with base coverage file provided

Describe a bug
The base coverage collection is still beeing skipped although a base coverage file is provided by the configuration. That means no coverage diff is reported on the PR comment.
My Bugfix from #239 was supposed to fix this issue but it does not seem to work.
I would look into it myself, but I do not have the time right now. If this is not picked up until next week I will come back to it myself.
Expected behavior
Base coverage is collected from the provided coverage file and coverage diff percentage is shown in the PR comment.
Also the branch should remain unchanged. We know it was working before when branches where switched, but that should be unnecessary and can cause other errors (see #236)
Details
Action version: 2.0.4
OS, where your action is running (windows, linux): linux
action.yml file
name: Test, build & Docker push
on: pull_request

concurrency:
  group: ${{ github.ref }}
  cancel-in-progress: true

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v3
        # We need full history for commitlint.
        with:
          fetch-depth: 0

      - name: Get coverage cache
        uses: actions/cache@v2
        with:
          key: base-coverage-${{ github.ref }}
          restore-keys: base-coverage-${{ github.base_ref }}
          path: ./coverage/base-report.json
      - name: Setup node
        uses: actions/setup-node@v2
        with:
          node-version: '16.14.0'
          cache: 'yarn'
      - name: Install project dependencies
        run: yarn --frozen-lockfile

      - name: Run linting
        if: ${{ false }}
        run: yarn lint
      - name: Run tests
        run: yarn test --runInBand --coverage --coverageThreshold '{}' --testLocationInResults --json --outputFile=./coverage/report.json

      # make sure the file exists
      - run: cat ./coverage/base-report.json
      - uses<EMAIL_ADDRESS>        # It will annotate failing tests as well, so we can run it always.
        if: always()
        with:
          github-token: ${{ secrets.GITHUB_TOKEN }}
          package-manager: yarn
          coverage-file: ./coverage/report.json
          base-coverage-file: ./coverage/base-report.json
          annotations: all
          skip-step: all

Screenshots

Additional context
Log output
Run<EMAIL_ADDRESS>  with:
    github-token: ***
    package-manager: yarn
    coverage-file: ./coverage/report.json
    base-coverage-file: ./coverage/base-report.json
    annotations: all
    skip-step: all
    test-script: npx jest
    icons: emoji
Run $GITHUB_ACTION_PATH/run.sh
  $GITHUB_ACTION_PATH/run.sh
  shell: /usr/bin/bash --noprofile --norc -e -o pipefail {0}
  env:
    INPUT_GITHUB-TOKEN: ***
    INPUT_TEST-SCRIPT: npx jest
    INPUT_THRESHOLD:
    INPUT_WORKING-DIRECTORY:
    INPUT_ICONS: emoji
    INPUT_ANNOTATIONS: all
    INPUT_PACKAGE-MANAGER: yarn
    INPUT_SKIP-STEP: all
    INPUT_CUSTOM-TITLE:
    INPUT_COVERAGE-FILE: ./coverage/report.json
    INPUT_BASE-COVERAGE-FILE: ./coverage/base-report.json
Running using node v16.14.0
Begin initialization stage...
Initialization stage ended
Begin stages.parsethreshold...
[...] (unrelated esbuild warning about jest.config.ts)
stages.parseThreshold ended
Begin head coverage collection...
Begin installing dependencies...
Installing dependencies skipped
Installing dependencies ended
Begin running tests...
Running tests skipped
Running tests ended
Begin collecting coverage...
Loading code coverage from file: coverage/report.json
Collecting coverage ended
Begin parsing coverage...
Parsing coverage ended
Head coverage collection ended
Begin switching to base branch...
Switching to base branch skipped
Switching to base branch ended
Begin base coverage collection...
Base coverage collection skipped
Base coverage collection ended
Begin switching back to original branch...
Switching back to original branch skipped
Switching back to original branch ended
Begin stages.checkthreshold...
stages.checkThreshold ended
Begin generating report...
Generating report ended
Begin report publish...
Report publish ended
Begin failed tests' annotations publication...
Failed tests' annotations publication skipped
Failed tests' annotations publication ended
Begin coverage annotations publication...
Coverage annotations publication ended

I am also having issues with the latest v2.0.4 and I have a similar setup where I run jest and collect coverage in separate steps and then use ArtiomTr/jest-coverage-report-action for the annotations.
     - name: Jest coverage report
        uses<EMAIL_ADDRESS>        with:
          github-token: ${{ secrets.GITHUB_TOKEN }}
          coverage-file: ./temp-coverage-results/current/jest.results.json
          base-coverage-file: ./temp-coverage-results/target/jest.results.json
          threshold: 80
          skip-step: all
          annotations: failed-tests

With v2.0.4 it keeps failing with TypeError: Cannot convert undefined or null to object and I am not sure how to debug it.

Out of curiosity I tried to use ArtiomTr/jest-coverage-report-action@Debug-action instead (mentioned in another conversation) and with that particular version it works perfectly.
I did some research but wasn't able to figure out where the Debug-action version comes from... is it based on an older version?! @ArtiomTr

@raspo,
The Debug-action is not a version, it is a branch. I created it from the main branch, so it should be the same as v2.0.4 version, with few console.log's added.
Looks like error occur on this line https://github.com/ArtiomTr/jest-coverage-report-action/blob/9ce24ef8d37706be462dcd6128760ea7f1c1857b/src/format/summary/getSummary.ts#L11
The variable map is null or undefined. I don't know what could cause that issue, but it is definitely is not related to this one. I will create a separate issue for this.

@ArtiomTr I tried the Debug-action branch and this bug is somehow fixed in there. No branch switches happening (so not an old version) and base coverage is loaded from the file.
I can reproduce it, v2.0.4 is skipping the base file, Debug-action is loading the base file.
I compared both branches and could only find console.log. Could the dist package be build differently?

@Raigen, I've added some tweaks & rebuilt the package - could you try it now?

I tried<EMAIL_ADDRESS>and it works as expected. Thanks!

@Raigen I was looking at your yml file and I was trying to understand something.
Did you commit base-report.json to your base branch first? as I can see you only output --outputFile=./coverage/report.json
I don't understand how this file is created especially because you do check if the file exists.
run: cat ./coverage/base-report.json
Thank you in advance.

@venux92 In my base branch I save the report with the cache action and load it in a PR with this:
      - name: Get coverage cache
        uses: actions/cache@v2
        with:
          key: base-coverage-${{ github.ref }}
          restore-keys: base-coverage-${{ github.base_ref }}
          path: ./coverage/base-report.json

By now we switched it over to an artifact, but the general idea is the same.


Refactor explicit FLS usage in the runtime

This change replaces explicit FLS usage for thread shutdown notification in the runtime into a
general thread shutdown callback registration mechanism.
The implementation using the FLS on Windows is moved to the PalRedhawkWinMin.cpp.
On Unix, it is implemented using TLS, since there are no fibers.

@jkotas, @smosier Can you take a look please?

Please note that setting the FLS value to the current thread pointer is now done before initializing the thread. I believe the change doesn't introduce any functional problem.

@smosier I was trying to preserve the saveguard checks in the ThreadStore::AttachCurrentThread, but  if we don't care about failing fast in case a thread is registered with a fiber and ThreadStore::AttachCurrentThread is called on another fiber and we are ok just doing nothing in that case, I could simplify it further by removing the isFirstAttach parameter of the PalAttachThread and returning from the ThreadStore::AttachCurrentThread without doing anything when the pAttachingThread->IsInitialized() is true.

Implements #640

LGTM otherwise

The original point of this fiber business was move the thread detach code to a place where the Win32 loader lock was not held.  It's been too long for me to remember much more detail, but I will dig into it and get back to you.  Do we have to worry about anything like the loader lock on unix?

@smosier There is not such issue on Unix.

@jkotas, @smosier  I have changed few things:

Removed the callback registration as you've suggested
Placed the registration code to PalInit
Removed the constructor attribute from the PalInit and add call to it to InitDLL instead so that it is called both on Windows and Unix

Link error on Ubuntu

@jkotas, the PalInit in PalRedhawkUnix.cpp was missing REDHAWK_PALEXPORT and REDHAWK_PALAPI annotation.

@jkotas, @smosier I have removed the isFirstAttach parameter from the PalAttachThread and submitted it as a separate commit so that you can compare it to the previous version.

LGTM

In general, I'd feel more comfortable about the FLS changes if you were to at least prototype the corresponding changes in the "app PAL" used by PN.  This would help us understand if there are any unique issues there which might affect the form of these changes.

@smosier I've reflected all your feedback. I am going to try to create the prototype change that you've asked for.

LGTM


Add support for manually capturing a profile

Closing this PR as it doesn't make sense to add this feature right now


Error on message import: "TypeError: Cannot read property 'timestamp' of undefined"

Sorry, to open another messaging related issue.
Just tested the new 0.3.34 build to import messages.
There now seems to be some sort of async collision, the slower I debug the code the more messages seem to get imported. Stacktrace start:
14/1 00:47 [17392] - error: TypeError: Cannot read property 'timestamp' of undefined
    at [...]\NodeBB\src\messaging.js:245:75
    at fn ([...]\NodeBB\node_modules\async\lib\async.js:746:34

Caller / trigger is line 1065 in importer.js
 Messaging.addMessage(fromUser.uid, toUser.uid, message._content, onAddMessage);

hmm ... and that didn't happen on 0.3.33 ?

I am not able to reproduce this, but I've made some changes, that might fix it you. One thing I also recommend is try to order by timestamp.  see https://github.com/belstgut/nodebb-plugin-import-phpbb/pull/1
You'd need to either send me a copy of the dump you're working with OR debug it with me. Just just the latest master instead of the 0.3.34

I could successfully import messages up to 0.3.34 before.
However, I did now downgrade to 0.3.33 again, and now get the same error as on 0.3.34. Some build dependency must have changed.
I did now publish my own fork of the nodebb-plugin-import-phpbb where I already integrated the pull request you did on belstguts fork: https://github.com/layernull/nodebb-plugin-import-phpbb
I did also try your new master of nodebb-plugin-import. Unfortunately, when loading the app I get
14/1 08:47 [10464] - error: Error: Cannot find module 'fs-extra'
at Function.Module._resolveFilename (module.js:336:15)
at Function.Module._load (module.js:286:25)
at Module.require (module.js:365:17)
at require (module.js:384:17)
at Object.<anonymous> ([...]\NodeBB\node_modules\nodebb-plugin-import\server\index.js:3:8)
at Module._compile (module.js:434:26)
at Object.Module._extensions..js (module.js:452:10)
at Module.load (module.js:355:32)
at Function.Module._load (module.js:310:12)
at Module.require (module.js:365:17)
at require (module.js:384:17)

14/1 08:47 [10464] - warn: [plugins] Unable to parse library for: nodebb-plugin-import
0.3.34 boots up fine.
.

error: Error: Cannot find module 'fs-extra'

if you're installing the master version, you need npm install its modules.

Yep, thanks. Got it to run, alas no joy, see updated comment. Still learning the ropes with Node.js app development. Great fun though.

I did now downgrade to 0.3.33 again, and now get the same error as on 0.3.34

I think your database is in a bad state. try to drop your mongo db and start fresh.
# 0 being the name of the default database, you could have called it something else, see your config.json

mongo 0 --eval "db.dropDatabase()"
./nodebb --setup # set up a fresh nodebb database again

see updated comment

I don't understand, I cannot see what got updated, can you strikethrough what's not valid anymore in your comment?

Sorry for any confusion! I did mention my updated comment because I had fixed and removed my problems with a 'fs-extra' a number of hours before you posted the fix.
Will test with a fresh mongoDB schema next.

I can confirm the TypeError disappeared with a fresh mongoDB setup!
This is rather worrisome, since I don't know what went wrong, so I am not sure how to prevent this from happening again.
Now everything seems to work, except for email auto confirmation. The "email:confirm" keys are still missing in the user objects. My old quick fix for this now fails, too.

This is rather worrisome, since I don't know what went wrong, so I am not sure how to prevent this from happening again.

The "email:confirm" keys are still missing in the user objects.

you mean email:confirmed? I think NodeBB changed the schema since I wrote that part. try it now against master.

I put my hot fix in the wrong file...
Yeah I mean "email:confirmed". The current master now sets the value, however it sets 0 instead of 1.

Ah, ok, i gtg run somewhere, will fix it when I get back.

No worries, the hotfix / workaround is easy, just replace
'email:confirmed': config.autoConfirmEmails ? 1 : 0,

with
'email:confirmed': 1

that should take care of the emails confirm checkbox value being false all the time.
https://github.com/akhoury/nodebb-plugin-import/commit/58b7a0ae5752792052f13654b81c0841231b7255

Fix looks good, thank you!

no worries.

I did re-import today, I can confirm the fix.

thanks


Move Lua VM to ITCM RAM

Take advantage of the new ITCM RAM support to dramatically speed up the Lua VM.
See: https://github.com/32blit/32blit-sdk/pull/737

Works for me... and a year has passed, think that's a long enough wait. :smile:

:laughing: thank you!


typo: netowork May double word the

Automation for azure-sdk-for-java

Automation for azure-sdk-for-python

Automation for azure-sdk-for-go

Automation for azure-sdk-for-js

Automation for azure-sdk-for-ruby

Can one of the admins verify this patch?


Issue 39: Create new DockerPlugin to run pipeline with Dockerfile

Merge Checklist

[ ] Have you linked this Pull Request to an Issue?
[ ] Have you updated any relevant README files, to explain how this new feature works (with examples)?
[ ] Have you added relevant test cases for your change?
[ ] Do all tests and code style checks pass with ./gradlew check --info?
[ ] Have you successfully run your change in a pipeline in a Jenkins instance?
[ ] Have you updated the CHANGELOG?

Codecov Report

Merging #102 (103f7fd) into master (686c71a) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #102   +/-   ##
=======================================
  Coverage   86.64%   86.64%
=======================================
  Files          21       21
  Lines         262      262
  Branches       54       54
=======================================
  Hits          227      227
  Misses          1        1
  Partials       34       34

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 686c71a...103f7fd. Read the comment docs.


Fix iframe for Google Sign-In

Details

The iframe around the Google Sign-In buttons started showing up unexpectedly on staging. It seems that dark theme can trigger this issue, so setting the button's container to have color-scheme: 'light' fixes it again.
Fixed Issues

$ https://github.com/Expensify/App/issues/25638
PROPOSAL: https://github.com/Expensify/App/issues/25638#issuecomment-1687254176
Tests

according to this guideline, to test this in dev you need to comment out the following code in the LoginForm.js file:
if (CONFIG.ENVIRONMENT === CONST.ENVIRONMENT.DEV) {
  return;
}

https://github.com/Expensify/App/blob/120bcbfde6d0ccfac8a63cf11a4aa7f769a048ea/src/pages/signin/LoginForm.js#L238-L238

log out if already logged in.
On the sign-in page, notice the google sign-in button.
Verify that no rectangular white container surrounds the Google sign-in button iframe.

[x] Verify that no errors appear in the JS console

Offline tests

N/A
QA Steps

Same as tests above.

[x] Verify that no errors appear in the JS console

PR Author Checklist

[x] I linked the correct issue in the ### Fixed Issues section above
[x] I wrote clear testing steps that cover the changes made in this PR

[x] I added steps for local testing in the Tests section
[x] I added steps for the expected offline behavior in the Offline steps section
[x] I added steps for Staging and/or Production testing in the QA steps section
[x] I added steps to cover failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
[x] I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)
[x] I tested this PR with a High Traffic account against the staging or production API to ensure there are no regressions (e.g. long loading states that impact usability).

[x] I included screenshots or videos for tests on all platforms
[x] I ran the tests on all platforms & verified they passed on:

[x] Android / native
[x] Android / Chrome
[x] iOS / native
[x] iOS / Safari
[x] MacOS / Chrome / Safari
[x] MacOS / Desktop

[x] I verified there are no console errors (if there's a console error not related to the PR, report it or open an issue for it to be fixed)
[x] I followed proper code patterns (see Reviewing the code)

[x] I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick)
[x] I verified that the left part of a conditional rendering a React component is a boolean and NOT a string, e.g. myBool && <MyComponent />.
[x] I verified that comments were added to code that is not self explanatory
[x] I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
[x] I verified any copy / text shown in the product is localized by adding it to src/languages/* files and using the translation method

[x] If any non-english text was added/modified, I verified the translation was requested/reviewed in #expensify-open-source and it was approved by an internal Expensify engineer. Link to Slack message:

[x] I verified all numbers, amounts, dates and phone numbers shown in the product are using the localization methods
[x] I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is approved by marketing by adding the Waiting for Copy label for a copy review on the original GH to get the correct copy.
[x] I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
[x] I verified the JSDocs style guidelines (in STYLE.md) were followed

[x] If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
[x] I followed the guidelines as stated in the Review Guidelines
[x] I tested other components that can be impacted by my changes (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar are working as expected)
[x] I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
[x] I verified any variables that can be defined as constants (ie. in CONST.js or at the top of the file that uses the constant) are defined as such
[x] I verified that if a function's arguments changed that all usages have also been updated correctly
[x] If a new component is created I verified that:

[x] A similar component doesn't exist in the codebase
[x] All props are defined accurately and each prop has a /** comment above it */
[x] The file is named correctly
[x] The component has a clear name that is non-ambiguous and the purpose of the component can be inferred from the name alone
[x] The only data being stored in the state is data necessary for rendering and nothing else
[x] If we are not using the full Onyx data that we loaded, I've added the proper selector in order to ensure the component only re-renders when the data it is using changes
[x] For Class Components, any internal methods passed to components event handlers are bound to this properly so there are no scoping issues (i.e. for onClick={this.submit} the method this.submit should be bound to this in the constructor)
[x] Any internal methods bound to this are necessary to be bound (i.e. avoid this.submit = this.submit.bind(this); if this.submit is never passed to a component event handler like onClick)
[x] All JSX used for rendering exists in the render method
[x] The component has the minimum amount of code necessary for its purpose, and it is broken down into smaller components in order to separate concerns and functions

[x] If any new file was added I verified that:

[x] The file has a description of what it does and/or why is needed at the top of the file if the code is not self explanatory

[x] If a new CSS style is added I verified that:

[x] A similar style doesn't already exist
[x] The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(themeColors.componentBG))

[x] If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
[x] If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
[x] If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
[x] If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
[x] If a new page is added, I verified it's using the ScrollView component to make it scrollable when more elements are added to the page.
[x] If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.
[x] I have checked off every checkbox in the PR author checklist, including those that don't apply to this PR.

Screenshots/Videos

Web

Mobile Web - Chrome

Mobile Web - Safari

https://github.com/Expensify/App/assets/77965000/8a42e35b-e592-4285-8f89-63244f21c706

Desktop

https://github.com/Expensify/App/assets/77965000/6457aca6-3d2a-455d-acde-bb6b887fd71f

iOS

https://github.com/Expensify/App/assets/77965000/9bb53b9a-3c73-4d16-a883-498ccde9c725

Android

https://github.com/Expensify/App/assets/77965000/4397a756-9a7e-48b1-8163-628b0b331d28

@rayane-djouah Please merge main into your branch and push the changes. It should be fixed now; sorry for the inconvenience 🙇🏼

Going to create an AdHoc test build on this PR just to see if it will work. Don't mind me...

Use the links below to test this build in android and iOS. Happy testing!

:test_tube::test_tube: Use the links below to test this build in android and iOS. Happy testing! :test_tube::test_tube:

android :robot:
iOS :apple:

https://ad-hoc-expensify-cash.s3.amazonaws.com/android/25645/index.html
❌ FAILED ❌

The QR code can't be generated, because the iOS build failed

desktop :computer:
web :spider_web:

https://ad-hoc-expensify-cash.s3.amazonaws.com/desktop/25645/NewExpensify.dmg
https://25645.pr-testing.expensify.com

:hand: This PR was not deployed to staging yet because QA is ongoing. It will be automatically deployed to staging after the next production release.

🚀 Deployed to staging by https://github.com/marcochavezf in version: 1.3.56-10 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅

Fixed on staging

🚀 Deployed to production by https://github.com/roryabraham in version: 1.3.56-24 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
failure ❌

🕸 web 🕸
success ✅

🚀 Deployed to staging by https://github.com/marcochavezf in version: 1.3.58-0 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅

🚀 Deployed to production by https://github.com/luacmartins in version: 1.3.58-5 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅


Reorganizing Debugging with Profiling

... and moving XHProf to that merge while fixing its name (using original case sensitivity)

I think a standalone Profiling category might be better. If you tweak the PR to do that I'll get it merged. Thanks.

I considered that too at first, but given that it is quite common (e.g.: Xdebug, Tracy and Z-Ray) that a tool mixes both aspects, I wondered how to manage that correctly and haven't found a good solution.
What about copying the lines into the different categories? Not a very elegant solution, but it would do the trick.

Good point. In that case I think your category name is probably a decent improvement. Thanks.


Always 'No reviews matched the request'

I install it in jira market place, and config it as the documentation says. But when i look at the issue, it always say "No reviews matched the request. Check your Options in the drop-down menu of this sections header.";  And when i manage the plugin, the "Test Config" button give no response.

jira version: v6.4
Gerrit Code Review for Jira: v. 2.3.1

The latest versions of the plugin (as of 3.0 and newer) do not support JIRA 6 or older.
What version of Gerrit do you use?  Also, check the search query string in Gerrit, and make sure that a search in Gerrit returns the commits that you're expecting. If not, then the plugin cannot possibly include that data, because that search is exactly how the plugin works.


Touchstone - Align Sender & Receiver Userstories

Sender userstory1 should be equivalent Receiver userstory1 and so on

Handled elsewhere


Error while retrieving information from server [DF-AA-20]

Every time i hit button on home page it shown me this error and when i search in internet it tell me publish ur app in alpha testing and i published app in alpha testing and again this error is happen i dont know why and some say replace your base64 string key in code but i didt see any where any key which is base64 string please help me to resolve this.

Hi,
There's no need to include your BASE_64_ENCODED_PUBLIC_KEY anywhere inside your project. Simply use this new BillingClient Library 'com.android.billingclient:billing:1.0' and make sure you use same Application ID (package name) that's been used in the play store and android project as well.

If you are experiencing like the above picture, please ensure that you have updated your APK in BETA Channel and make sure you are using same package name in Play Store and and in your project as well.


complie failed use clang

I meet a problem when I compile openssl:
here is details:
"crypto/thread/arch/thread_posix.c:25:5: warning: implicit declaration of function 'pthread_setcancelstate' is invalid in C99 [-Wimplicit-function-declaration]
pthread_setcancelstate(PTHREAD_CANCEL_ENABLE, NULL);
^
crypto/thread/arch/thread_posix.c:25:28: error: use of undeclared identifier 'PTHREAD_CANCEL_ENABLE'
pthread_setcancelstate(PTHREAD_CANCEL_ENABLE, NULL);
^
crypto/thread/arch/thread_posix.c:26:5: warning: implicit declaration of function 'pthread_setcanceltype' is invalid in C99 [-Wimplicit-function-declaration]
pthread_setcanceltype(PTHREAD_CANCEL_ASYNCHRONOUS, NULL);
^
crypto/thread/arch/thread_posix.c:26:27: error: use of undeclared identifier 'PTHREAD_CANCEL_ASYNCHRONOUS'
pthread_setcanceltype(PTHREAD_CANCEL_ASYNCHRONOUS, NULL);"
compile tools is x86_64-linux-android28-clang , I don`t know what I can do to fix this problem.

Did you read and follow the notes in the NOTES-ANDROID.md file?
It's also worth reading the INSTALL.md instructions.
If you did both of these, you need to disable threading support.  That's in those documents.

Try #19695
With that you should be able to configure with no-thread-pool and it should compile fine for you.


[pigeon] ObjC generator doesn't handle nullable enum fields correctly

The AllNullableTypes nullable enum field, which is
  AnEnum? aNullableEnum;

generates
@property(nonatomic, assign) AnEnum aNullableEnum;

That can't express a null value. Currently what happens is you get whatever 0 maps to in the enum, which is wrong.
IIRC @gaaclarke and I have discussed this in the past; using NSNumber like we do for other numeric types means clients have to cast, which isn't great. Options I can see include:

Use a sentinel value corresponding to null, but we'd have to be careful about naming collisions. (I think this was suggested at the time, I forget whether there are other problems we discussed with that approach.)
Generating a wrapper class in the case of a nullable enum, that would behave sort of like C++'s std::optional.

(Support this isn't that important in practice, since "nullable enum" is kind of a weird concept and thus unlikely to come up much in practice, and it's easy for clients to work around by making it non-nullable with an explicit null state, but we should at least be erroring out during generator validation instead of generating incorrect code.)

Generating a wrapper class in the case of a nullable enum, that would behave sort of like C++'s std::optional.

Since we don't have templating in ObjC, I think we'd need to generate a class per nullable enum. The class would be trivial though, something like:
@interface NullableMyEnumType : NSObject
@property(nonatomic, assign) MyEnumType value;
@end

The @implementation would be empty since property synthesis would take care of the rest.


How to add plugins for waypoint follower in linorobot2

I need to set delay when waypoint goal is reached once.
There is plugins available how to execute those plugins.

Hi, this question is more related to Nav2. Please post this on ROS answers


Multi-Viewport Support?

Any support for the Multi-Viewport feature? https://github-wiki-see.page/m/ocornut/imgui/wiki/Multi-Viewports

Might not be the answer you were looking for, but the net_imgui branch could allow you to have the Dear ImGui content displayed outside of the game screen, without using the Viewport support itself. The UnrealNetImgui plugin could also allow that, without any Dear ImGui content possible on the game screen however.
Adding Viewport support to Unreal would not be trivial I fear.


Running sever in production ENV with craco start

Here is the full error log on running below command. I using latest version 5.6.4
$ NODE_ENV=production craco start
Please have a look
/Users/satendra/workspace/recast-app/node_modules/@craco/craco/lib/plugin-utils.js:29
    throw new Error(
    ^

Error: Found an unhandled loader in the production webpack config: /Users/satendra/workspace/recast-app/node_modules/style-loader/index.js

This error probably occurred because you updated react-scripts or craco. Please try updating craco-less to the latest version:

   $ yarn upgrade craco-less

Or:

   $ npm update craco-less

If that doesn't work, craco-less needs to be fixed to support the latest version.
Please check to see if there's already an issue in the FormAPI/craco-less repo:

   * https://github.com/FormAPI/craco-less/issues?q=is%3Aissue+webpack+unknown+rule

If not, please open an issue and we'll take a look. (Or you can send a PR!)

You might also want to look for related issues in the craco and create-react-app repos:

   * https://github.com/sharegate/craco/issues?q=is%3Aissue+webpack+unknown+rule
   * https://github.com/facebook/create-react-app/issues?q=is%3Aissue+webpack+unknown+rule

    at throwUnexpectedConfigError (/Users/satendra/workspace/recast-app/node_modules/@craco/craco/lib/plugin-utils.js:29:11)
    at throwError (/Users/satendra/workspace/recast-app/node_modules/craco-less/lib/craco-less.js:14:5)
    at /Users/satendra/workspace/recast-app/node_modules/craco-less/lib/craco-less.js:119:7
    at Array.forEach (<anonymous>)
    at Object.overrideWebpackConfig (/Users/satendra/workspace/recast-app/node_modules/craco-less/lib/craco-less.js:51:11)
    at overrideWebpack (/Users/satendra/workspace/recast-app/node_modules/@craco/craco/lib/features/plugins.js:42:40)
    at /Users/satendra/workspace/recast-app/node_modules/@craco/craco/lib/features/plugins.js:64:29
    at Array.forEach (<anonymous>)
    at applyWebpackConfigPlugins (/Users/satendra/workspace/recast-app/node_modules/@craco/craco/lib/features/plugins.js:63:29)
    at mergeWebpackConfig (/Users/satendra/workspace/recast-app/node_modules/@craco/craco/lib/features/webpack/merge-webpack-config.js:67:30)

Note: The log suggests to update craco-less but the issue still exists.

Hi @satendra02
Have you tryed posting the issue on https://github.com/DocSpring/craco-less repository? Seems related to the plugin not to the core of CRACO.


How to get the progress of the uploading?

How can I add a progress bar that shows the progress of the upload?

R = new Resumable({})
R.on('fileProgress', (file, ratio) => {
   console.log(file.progress());
});


Fix a few typos

Thanks :)

You're welcome. Easy for my fresh, naïve eyeballs to notice. ¯\_(ツ)_/¯


ESP32 compatibility

Hi madpilot, thank you for your work.
Do you think this library could work with an ESP32?

In theory, yes. The UDP library is the same.
In practice, I don’t know - I don’t have the hardware - i’m not sure how ready the Arduino stuff is on that platform.
Closing this as it, technically not an issue until some one tries it and it doesn’t work.
If you try it and it fails, please open another issue.

@palmerabollo @madpilot
Compiling .pioenvs/lolin_d32_pro/lib6a8/mDNSResolver/mDNSResolver.cpp.o
.piolibdeps/mDNSResolver/src/mDNSResolver.cpp: In member function 'void mDNSResolver::Resolver::query(const char*)':
.piolibdeps/mDNSResolver/src/mDNSResolver.cpp:67:9: error: 'class WiFiUDP' has no member named 'beginPacketMulticast'
udp.beginPacketMulticast(MDNS_BROADCAST_IP, MDNS_PORT, localIP, UDP_TIMEOUT);
^
.piolibdeps/mDNSResolver/src/mDNSResolver.cpp: In member function 'unsigned int mDNSResolver::Resolver::read()':
.piolibdeps/mDNSResolver/src/mDNSResolver.cpp:89:63: error: no matching function for call to 'WiFiUDP::beginMulticast(IPAddress&,
IPAddress, int)'
udp.beginMulticast(localIP, MDNS_BROADCAST_IP, MDNS_PORT);
^
In file included from .piolibdeps/mDNSResolver/src/mDNSResolver.h:5:0,
from .piolibdeps/mDNSResolver/src/mDNSResolver.cpp:1:
<EMAIL_ADDRESS>57:11: note: candidate: uint8_t WiFiUDP::beginMulticast(IPAddress, uint16_t)
uint8_t beginMulticast(IPAddress a, uint16_t p);
^
<EMAIL_ADDRESS>57:11: note:   candidate expects 2 arguments, 3 provided
Compiling .pioenvs/lolin_d32_pro/FrameworkArduino/IPAddress.cpp.o
Compiling .pioenvs/lolin_d32_pro/FrameworkArduino/IPv6Address.cpp.o
*** [.pioenvs/lolin_d32_pro/lib6a8/mDNSResolver/mDNSResolver.cpp.o] Error 1
========================== [ERROR] Took 2.75 seconds ==========================


Discussion: How to style mux-player component

I cannot find a proper way to style mux-player component. I know under the hood mux-player is using video component for which I used to have a separate CSS file. However, is there any way to style mux-player?

Currently the styling options are somewhat limited but we are planning to add theming support later this year.
There are 2 attributes that can be set that will change the colors of the icons and the controls background.
for example:
primary-color="green"
secondary-color="red"
also have a look at this demo with color pickers
https://elements-demo-nextjs-1l4t1uk3r-mux.vercel.app/MuxPlayer


lib: thrift: TFDServer: fix multiple issues

xport: leaking eventfd descriptors
xport: interrupt() should close the eventfd
TFDServer: methods missing override keyword in class definition
TFDServer: isOpen() and close() methods missing
xport: negative result from isOpen() should either return 0
or throw TTransportException
TFDServer: clear children when interrupted
xport: POLLNVAL not considered in read_virt()

Fixes #115

I would like to fix the issue with hello flaking-out on qemu_cortex_a53_smp if possible


Speed up recognize punctuation

The original code in function 'read_punct' relies on heavy string specific function calls, resulting in slower execution. Instead, this function can be faster using straightforward control flow.

case '\\' cannot be ommited here, since preprocessing is a separate pass after tokenization, we need to allow Windows paths like #include <sys\stat.h> even if they are conditioned in #if blocks.
case '$' should be safe to omit since it's unreachable after is_ident2().
It's a good chance to also specialize TokenKind with dedicated enums like TK_PUNCT_COMMA and reduce some equal()s.
This part also looks eligible for SIMD/SWAR techniques like simdjson, fun but error prone.

With c7ae74f, backslash \ in Windows path don't need to be tokenized.
Furthermore if one doesn't need to support -E output and assume valid C source, backslash \ and other characters like @ that don't appear in C syntax can even be simply skipped like:
diff --git a/tokenize.c b/tokenize.c
index 6ecbd92..81e7dfd 100644
--- a/tokenize.c
+++ b/tokenize.c
@@ -690,8 +690,7 @@ Token *tokenize(File *file, Token **end) {
       p += cur->len;
       continue;
     }

-    error_at(p, "invalid token");
+    p++;
   }

This might give compiler more room to optimize the hot loop.

I removed the merge from commit history due to over-resemblance to this commit from another chibicc fork, authored two months earlier:
https://github.com/enh/chibicc/commit/a3645309bd3b5bb4a214e28703cd1d93fda96568


Updates to documentation

I don't see what changed. Can you explain the difference? Also there is just one file maintained with drawio for the architecture. The other SVGs were exported by activating the individual layers.


Save-PnPTenantTemplate : Value cannot be null.

Hi,
Trying to modify Site Title and Display name in marketing landing site from sp-dev-provisioning-templates-master but its throwing error "Value cannot be null". using below powershell to save updated template:
$kit = Read-PnPTenantTemplate -Path .\starterkit.xml
Save-PnPTenantTemplate -Hierarchy $kit -Out yourstarterkit.pnp

Hi, is this still an issue for you, was it ever resolved?