UX Issue on Private smallcases page

Hey team, I know this ain't the right repository to create this issue but I can't see any other relevant repo for this bug.
On your web app, In the private smallcases pages "Request for an invite" button doesn't trigger your mailer system backend properly. It does redirects to the automated mail of subscribing to the smallcase but in your backend, the invite code doesn't get triggered to be sent to the user.
THIS SEEMS TO BE MAJOR UX ISSUE. I myself have waited for more than 6 days to get an invite but haven't received any.
There's a workaround for this though. We need to log out and open the page in incognito mode and then complete the payment process in order to subscribe to that smallcase.
"Request for invite" program is gimmicky and became a thing of the past. You folks have already established your brand and no more need to build the hype.
P.S - Apologies for hasty english. ( I have a sprint review meeting coming up soon otherwise I would have written it in a proper markdown format).
HMU if you want me to explain the bug in a more clear manner or reproduce it.

I'm talking about this Blue request for invite button.

Hey we have noted this issue and will look into it.
If you need any help regarding this or general feedback, please contact us through<EMAIL_ADDRESS>thank you!


Allow reducing image to avoid upload large image

Decoding Image to reduce size
produce thumbnails

You can get the image path on the Image result. You can scale it in your app logic by yourself.
I think this should not the library responsibility/feature.


[Feature Request] Support for Border Related props and borderRadius styling.

It would be awesome to be able to create rounded AR components. Much of our UI is rounded or has the border radius style, and it would be helpful to have that style available in AR as well.

is there a way to make an ViroImage to appear with a border radius ? I mean the original image is rectangle but I want it to appear with a round frame?

@Ashkan-Oliaie did you find any solution?


Using config_template

Thanks to @cloudnull great patch at
https://github.com/ansible/ansible/pull/12555
we now have the ability to add more configuration options instead of
having to push a PR to add a new option to the template. So you can
dynamically add and remove flags.
To use it, edit ceph_conf_overrides in group_vars/all like so:
ceph_conf_overrides
 global:
     foo: 12345
     bar: 6789

Signed-off-by: Sébastien Han<EMAIL_ADDRESS>

@cloudnull while trying to add new values, I'm getting the following error: http://pastebin.com/bx248qVv
Any inputs would be appreciated, thanks :)

hum looks like 'indent' are not supported/compliant with the INI style format...

Sorry for everyone using the module already. This will likely perform a restart of the cluster while running the playbook again since the structure of the ceph.conf will change. One thing to do is to remove all the indent from the ceph.conf.

@leseb Just following up, I've been on holiday for the past little bit. While it seems like all is well I wanted to follow up to make. Was everything figured out regarding the config_template?

@cloudnull Hey! No worries, thanks for catching up :). Yes once I figured the indent issue everything went smooth. Thanks again for this module. Hopefully it'll get merged next early next year.


[CHORE] Deploy node sale contract for PTN testing

Deploy the node sale contract for testing in private testnet
Compass address on Arbitrum: 0x9D352C4a98d9C1bBede3441740aD88018aF347F3

https://arbiscan.io/address/0xF125C18161C833a386A02214256c521f9e64F967
@verabehr

@verabehr should i deploy the cosmwasm contract too?

thanks @fullstack412 - updated contract in vercel


Improved CSS styling

Enhance Styling of Movie Poster Images on Mobile Screens.
Description:
This PR addresses the styling issue identified in #1
Changes Made:

Adjusted the height of movie poster images for optimized display on mobile screens.
Ensured that modified heights maintain the aspect ratio of the original images.

Merge approved. Thank you for contributing. Appreciate. Good job!


Feature update README: CMake section + Issues

I tried to use this library for my educational purposes. However, on my platform macOS Catalina, I ran into some problems that I successfully solved after some time. I suggest you adding this information to the readme, to make it simple to understand for other people faced this problems.

Hi, thanks for contributing! :)
This already looks good, but if the previous description is actually outdated I think it's fine to be a bit more radical and to just remove it from the README completely. (I usually don't use CMake, so I can't really judge myself). Or, at least the recommended way should be listed first and more prominently than the deprecated way.

@lava Since FindPython is a feature of CMake 3.12+, I would recommend to keep both ways - legacy and recommended. But I put recommended way first, as you have suggested, also I provided it with minimum required version of CMake.

Merged, thanks again for contributing!


Support pagination for get_registered_ip

possible implementation for getting all registered
ips without the 500 item limit.
This implements enhancement request issue 152

Thanks for submitting this!  We'll review, test, and get back to you.

After thinking about it a bit, I think it's more appropriate to raise an exception instead of doing warnings.warn().  Getting 0 results back is only valid if there are 0 registered IPs, which is not the case.  It is more correct to raise PanDeviceError(.....) if you get that logfile response in pre-PAN-OS 8.0.

Thanks for the comments shinmog. Sorry for the late response, but it has been quite busy. Considering your comments I don't think I'll have time to make updates in the short run. Can I ask you to pick from here and implement your suggestions yourself?

@mirakels
Yep, thanks for working on this, I can take it from here.  Very much appreciate the time you've put in to fixing this!


get luminance doesn't always return the correct number

Hi, I am using two display for MacStudio, one is LG 27UP850 (display 1), another one is LG 27UP650. I am trying to combine Hammerspoon and m1ddc together. I want to know the current brightness before I change it, however, the command
m1ddc display 1 get luminance

doesn't always return the current brightness (which is 50 during my test), sometimes it returns 0 and I see one time it returns a negative number, as you can see from the image

For get volume I have the same problem too..

well, you should make an iteration in your luascript to get the value 5 times and use the max you get. DDC reading is inherently finicky.

thanks, at least I have a solution now.


Mkdir -p functionality

Hey guys what do you think about adding the functionality for mkdir -p (recursive directory creation) to S3FS? Currently, the NodeJS FS implementation does not have this ability.
I could add it for S3 and FS file systems.

So we actually have this already implemented through our FS Mixins which can be used for S3FS/FS/FSP/etc. to achieve making the directories recursively. As for S3FS this shouldn't really matter since S3 doesn't consider a folder to be an object. So if you create something in a directory that doesn't exist it will just make it there no problem.
I'm planning on implementing a simple mkdirp for S3FS once I get some time since it would just need to make one call non-recursively to create all the directories.

Cool, that is exactly what I needed


cooperative yield in ThreadPool::install() causes unexpected behavior in nested pools

It appears calls to ThreadPool::install(op) will start running op inside the child thread pool and then cooperatively yield, potentially switching to a different task. This causes unexpected behavior with nested iterators using thread pools.  It would be nice if rayon didn't yield on ThreadPool::install(), or if the authors believe that it should yield, to place some kind of warning in the documentation for ThreadPool::install().
Consider the following example.  You have an outer loop that performs some operation that requires a lot of memory.  You have an inner loop that uses a lot of cpu but is memory-efficient.  To avoid unbounded memory growth, you will run the outer and inner loops in separate thread pools where ncpus_outer is a small number and ncpus_inner is a big number.
let pool_outer = ThreadPoolBuilder::default().num_threads(ncpus_outer).build().unwrap();
let pool_inner = ThreadPoolBuilder::default().num_threads(ncpus_inner).build().unwrap();
pool_outer.install(|| {
    some_par_iter.for_each({ |foo|
        println!("Entered outer loop.");
        let bar = memory_intensive_op(foo);
        pool_inner.install(|| {
            println!("Entered inner pool.");
            thing.into_par_iter().for_each({ |baz|
                cpu_intensive_op(baz);
            });
        });
        println!("Left inner pool.");
    });
});

Suppose ncpus_outer is equal to one.  You might reasonably expect that only one bar will be allocated at any given time, giving you control over memory use.  However, the output of the program may actually look like:
Entered outer loop.
Entered inner pool.
Entered outer loop.
Entered inner pool.
Entered outer loop.
Entered outer loop.
Left inner pool.
...

This is possible because, rather than blocking until pool_inner.install() returns, the outer thread pool will yield and cooperatively schedule another iteration of the outer loop on the same thread. This gives you essentially zero control over how many instances of bar will be allocated at a given time.
This is an even bigger problem if you have to do some kind of synchronization (yes there are real uses cases for this):
let pool_outer = ThreadPoolBuilder::default().num_threads(ncpus_outer).build().unwrap();
let pool_inner = ThreadPoolBuilder::default().num_threads(ncpus_inner).build().unwrap();
let mutex = std::sync::Mutex::new(());
pool_outer.install(|| {
    some_par_iter.for_each({ |foo|
        println!("Entered outer loop.");
        let bar = memory_intensive_op(foo);
        let lock = mutex.lock();
        pool_inner.install(|| {
            println!("Entered inner pool.");
            thing.into_par_iter().for_each({ |baz|
                cpu_intensive_op(baz);
            });
        });
        println!("Left inner pool.");
        // Mutex lock released here.
    });
});

Entered outer loop.
Entered inner pool.
Entered outer loop.
[ deadlock ]

The outer thread pool yields to a different task before releasing the mutex, likely leading to a deadlock unless it switches back to the task holding the mutex before it runs out of threads in the outer pool.

I do think yielding is the appropriate default behavior, and documentation PRs are fine to clarify this. I think we could also add a variant or two of install with different behavior. Here's the current install behavior, and some thoughts:

If you're not in any pool, queue the work in the target pool and then block.

This should be uncontroversial.

If you're in a different pool, queue the work in the target pool and then yield.

We could add a mode that blocks here instead. The potential downside is that this pool could get completely blocked, and even cause deadlocks if any of that inner pool work tries to queue and wait for any work back in the outer pool. But as long as you know there's no "loopback", it may be fine.

If you're already in the target pool, execute it directly.

Note that this may also lead to work-stealing of outer work if it ends up waiting for other threads to complete its inner work.
We could have an even stronger mode that blocks here as well, but that would have an even higher risk of deadlocking if all its threads are tied up this way.

BTW, your Mutex scenario is also discussed in #592, which may or may not involve multiple pools.

@cuviper, I appreciate your explanation of the install() behavior.  I do want to make an important distinction that yielding is not the opposite of blocking.  For example, consider the behavior of tokio::spawn():
statement1;
let handle = spawn(async { some_work });
statement2;
handle.await.unwrap();

statement1 is executed on what we'll call thread1.  The call to spawn() returns immediately without blocking.  statement2 is executed on thread1.  Then the call to await blocks, potentially yielding execution to another task on thread1.  Here, the non-blocking spawn and the yield occur in different statements, ensuring that statement2 will always execute after statement1 on thread1. Furthermore, the explicit await syntax makes it obvious to the programmer where the yield point is.

If you're in a different pool, queue the work in the target pool and then yield.
* We could add a mode that blocks here instead. The potential downside is that this pool could get completely blocked, and even cause deadlocks if any of that inner pool work tries to queue and wait for any work back in the outer pool. But as long as you know there's no "loopback", it may be fine.

In the simplest case:
some_par_iter.par_for_each(|| {
    statement1;
    other_pool.install(|| { some_work; });
    statement2;
}

There is no need to make install() block here.  It could queue the work on the other threadpool and then return immediately just like spawn().  What's confusing is that install() doesn't just not block -- it also yields, which means there may be several calls to statement1 before statement2 ever gets a chance to execute.  Rayon's syntax doesn't make yield points explicit, and the implicit yield is not documented (except in this GItHub issue).  This leads to surprising results not only with mutexes as in #592, but also with unbounded memory growth and stack overflows as mentioned in my first comment.  Even more surprisingly, install() may or may not implicitly yield() depending on the context!
IMHO, if we were writing Rayon from scratch, I would suggest making all yields explicit.  The default behavior would then be expressed as follows.  Making the yield explicit makes the behavior obvious to the programmer, and it also gives the programmer the choice of moving statement2 up between install() and yield().
some_par_iter.par_for_each(|| {
    statement1;
    other_pool.install(|| { some_work; });
    rayon::yield_now();
    statement2;
}

I do think yielding is the appropriate default behavior, and documentation PRs are fine to clarify this. I think we could also add a variant or two of install with different behavior.

I have to agree, but only because changing the behavior of install() could cause deadlocks in existing code that depend on the implicit yield.  I would love to see clearer documentation and a yield-free versions of install() and similar methods (not sure if spawn() can yield in rayon).  It looks like this would require some intimate work on unsafe parts of rayon.  Do you envision this as something a maintainer might work on, or something you would like an outside PR for?

In the simplest case:
some_par_iter.par_for_each(|| {
    statement1;
    other_pool.install(|| { some_work; });
    statement2;
}

There is no need to make install() block here.

Since install returns a value, that is inherently blocking with respect to following statements. It also allows borrowing since its closure is not constrained to 'static lifetimes -- from the compiler borrowck perspective, those borrows only last for the duration of this call, so we cannot safely return until we're done with that work. If you don't want that imperative control flow, that's what ThreadPool::spawn and Scope::spawn are for.
So when I talk about yielding vs. blocking here, I'm only talking about what the thread should do while it waits, but we do have to wait for install completion regardless.
We've also had discussions about actual awaitable futures, like my old WIP #679, but that didn't address the executor part, which you would need if you wanted to await that within a parallel for_each -- or at least a block_on kind of thing.

I would love to see clearer documentation and a yield-free versions of install() and similar methods (not sure if spawn() can yield in rayon). It looks like this would require some intimate work on unsafe parts of rayon. Do you envision this as something a maintainer might work on, or something you would like an outside PR for?

The design is the more interesting part that needs discussion. Regarding spawn, that only queues the work and returns right away. The other main primitives are join and scope, but I think it will get a lot hairier if we try to add variations of those, and I haven't fully thought about those implications. Higher-level stuff like the parallel for_each also runs on join, and I definitely don't want to fork the entire ParallelIterator API.
Another idea that I've raised before is that we could have a kind of "critical section" call, inhibiting all work-stealing on that thread until that call returns. (Possibly with some nuance like allowing local work-stealing of work queued while in that call.) This might be a better way to have broad impact without forking a bunch of APIs.
If we decide on just adding install variations, I can mentor the implementation if you're keen, and as a first step take a look at Registry::in_worker. The variations I described before are pretty much contained in the three different branches in that function, where the "cold" part is the fully blocking case.
https://github.com/rayon-rs/rayon/blob/7449d7dfede9bd1e2bde0c898b20f46db70a1ac2/rayon-core/src/registry.rs#L486-L504
The cold path currently debug_assert!s that it's not in any pool though, so we'd have to re-evaluate that at least. In a way, that represents the philosophy of the current design, that pool threads should always be trying to find work -- but I do think there are reasonable scenarios, like yours, where it makes sense to opt out of that work-stealing behavior.

Since install returns a value, that is inherently blocking with respect to following statements. It also allows borrowing since its closure is not constrained to 'static lifetimes -- from the compiler borrowck perspective, those borrows only last for the duration of this call, so we cannot safely return until we're done with that work. If you don't want that imperative control flow, that's what ThreadPool::spawn and Scope::spawn are for.

Ah, I stand corrected.  Since install() borrows and returns a value, it must either block or yield before returning.

If you don't want that imperative control flow, that's what ThreadPool::spawn and Scope::spawn are for.

I'll refactor my code with spawn() and scope().

Another idea that I've raised before is that we could have a kind of "critical section" call, inhibiting all work-stealing on that thread until that call returns. (Possibly with some nuance like allowing local work-stealing of work queued while in that call.) This might be a better way to have broad impact without forking a bunch of APIs.

This sounds difficult to implement, but it sounds like it would be the most ergonomic solution in the long term.


Integrate tqec with LaSsynth

Is your feature request related to a problem? Please describe.
What is LaSsynth?
LaSsynth is a synthesis for lattice surgery subroutines. After specifying the desired inputs/outputs ports and the stabilizer flows, it will use a SAT solver to solve the internal structure of the lattice surgery construction under limited spacetime volume. You can take a look at this demo to learn more about it.
Why is it useful for tqec?

LaSsynth provides a way to automatically construct a valid spacetime model but can not run simulations for it. Then it's natural to take the output of LaSsynth as the input of tqec to run and verify the construction at the circuit level.
LaSsynth provides a text format representation(LaSre) of the spacetime model and it can be taken as a starting point for the design of a portable text format of tqec computation structure.
LaSsynth provides the functionality to convert a LaSre file to a .gltf model and visualized the model as well as the correlation surfaces.
LaSsynth provides the functionality to convert a LaSre file to the corresponding zx diagrams(using stimzx) representation and verify the the stabilizer flows.

How it can be used with tqec?
LaSsynth provides a representation of the Lattice Surgery subroutine in a text format called LaSre.

LaSre of CNOT

It can be seen as a complete description of the structure of a 3D spacetime model or our BlockGraph. To be more specific:

n_i/j/ks specify the the spacetime volume
n_p/ports/port_cubes specify the number and positions of inputs/outputs of the subroutine. And these ports can corresponds to the virtual cubes in the BlockGraph.
n_s/stabs specifies the stabilizer flow generators. The concept of the stabilizer flow translates naturally to the correlation surface in the lattice surgery model. And it relates to the existing correlation subgraphs in BlockGraph.
ExistI/J/K specifies the positions of block structures including the cubes and pipes.
ColorI/J specifies the type of the block structures.
CorrIJ... specifies the explicit correlation surfaces presented in each pipe for each stabilizer flows.
NodeY specifies the existence of the Y basis initialization/measurements, which currently is not implemented in tqec but is planned for sure.

As above, the one-to-one translation between LaSre and BlockGraph should be possible.
Limitations
To integrate the two libraries, there are some problems that we need to solve in my mind:

Spatial Hadamard in LaSynth is not allowed by default, but can be enabled with some changes to the code.
Y cubes need to be implemented in tqec, or turn off the option for now.
If we want to use LaSre to represent the BlockGraph, we need to be able to fill the ports with actual cubes, which corresponds to logical initialization/measurements that instantiate a subroutine into a real computation.

I agree that this would be a very sensible and interesting addition. It might be too soon though. In my opinion, here are the steps we should focus on right now:

Have a fully working logical CNOT computation. This has been our main goal since the beginning, we are very close now, so we should prioritize as much as possible that goal.
Clean up the code, removing/simplifying/refactoring everything to have a clean code base that can still output a fully functional CNOT. This includes (non-exhaustive):

Template refactoring,
A huge documentation and testing improvement,
Removing now useless code,

Implement new features with the stabilized and cleaned-up code base.

I think this feature is 1) not needed for the completion of our first goal and 2) can wait until we finished cleaning up the codebase. An argument for implementing that now (instead of waiting) is that this feature is, at its core, "just" a translator from LaSre to BlockGraph, which only requires the API to create a BlockGraph instance (i.e., a small portion of the API) and so might not be impacted too much by a refactor.
Any opinion?

Yes this should not be a goal for the near term and I should note that in the first place. I had conversation with Austin about LaSsynth some times ago but forgot to write it up as an issue... And I do think it won't take too much work to implement this feature after finalizing and refactoring our library.

Would be great to get you to review the current status of this tool in a
future meeting.
On Tue, Sep 3, 2024 at 12:27 AM Yiming Zhang @.***>
wrote:

Yes this should not be a goal for the near term and I should note that
in the first place. I had conversation with Austin about LaSsynth some
times ago but forgot to write it up as an issue... And I do think it won't
take too much work to implement this feature after finalizing and
refactoring our library.
—
Reply to this email directly, view it on GitHub
https://github.com/QCHackers/tqec/issues/315#issuecomment-2325791640,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAKAXTF4ZMFE7SV63K4VI33ZUVQH7AVCNFSM6AAAAABNRFITYCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMRVG44TCNRUGA
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>


How to Start WakaQ

This is missing from the README. :)

Related: there are no details about how to configure redis access.

Added with 165e6c72cffdb434523b9bf257d25e8d5b09ad58


small typos and edits in first few pages

Some small typos, markdown lints and other wording tweaks I noticed while reading. Hopefully nothing controversial.
Just a few pages in so far; I'll add more as I go.
One question: the current content uses "directional" apostrophes, it’s vs it's, that gets caught by my spell-checker. Before I go changing them, is this deliberate / preferred?

On apostrophes, I think that's what the markdown implementation does... Or can you point me at a line that does that?

Fixed a merge problem.

On apostrophes, I think that's what the markdown implementation does... Or can you point me at a line that does that?

I don't mean in the rendered output (from the markdown implementation), I mean in the source, eg:
https://github.com/async-rs/async-std/blame/master/docs/src/concepts/futures.md#L108

Right, I see. That's a bug, it only occurs at 3 places. I'll fix that, thanks!

Thanks!


test_polygon.py has web3.exceptions.ExtraDataLengthError. Likely fix: add POA middleware

Encountered this error when updating brownie to latest version.
Solution: Inject POA middleware for polygon test.
 "
                "It is quite likely that you are connected to a POA chain. "
                "Refer to "
                "http://web3py.readthedocs.io/en/stable/middleware.html#geth-style-proof-of-authority "
                "for more details. The full extraData is: %r" % (
                    len(result), MAX_EXTRADATA_LENGTH, result
                )
            )
E           web3.exceptions.ExtraDataLengthError: The field extraData is 97 bytes, but should be 32. It is quite likely that you are connected to a POA chain. Refer to http://web3py.readthedocs.io/en/stable/middleware.html#geth-style-proof-of-authority for more details. The full extraData is: HexBytes('0xd482021083626f7286676f312e3139856c696e757800000000000000000000004c224cdb9f84d5b746cec3aeeb413bc9827271f82fc7422a1be93565163f316e6cf4fb1df46487aac057cb9a8c77e743ea9a37e09505b783f8bde3bda9452eed01')

Also: isn't the fix in the wrong spot? Unit tests are meant to catch issues in a general way; fixes should be general too, not just for the test.

Should we place the fix in our remote config instead of directly put it into the test as you mentioned @trentmc?

Definitely not the test, as I mentioned.
Well, Brownie is supposed to fix it, as of May 2020. Details.

If that's truly just the case, if we do this right, maybe it's changing just one line in just the right way

But some people still had the issue in Aug 2021. Details. However, there are still people commenting as of spring 2022.
My suggestion: dig through the above. Google around more. Lotsa people are probably using brownie * polygon, so how do they solve it?

Sorry for the late response. I searched this issue and found some PRs from web3.py which are related: 1 and 2.
2 is still open and the suggestion was to switch to another test network since also Goerli changed to PoS as polygon is.
The POA thingie won't work since Polygon is a PoS chain.
In 1, it was suggested to create a custom middleware for polygon or to sign transaction with local accounts, which is not a proper solution since we don't use send_transaction or send_raw_transaction. The issues from the Appendix refer mostly to PoA chains, such as Rinkeby.
My approach on this test particulary is to put ExtraDataLengthError into some skippable errors list until web3.py provides support for Polygon as well. What do you think @trentmc ?

Thanks for digging into this and what you learned!

My approach on this test particulary is to put ExtraDataLengthError into some skippable errors list until web3.py provides support for Polygon as well. What do you think @trentmc ?

Given that there's no clear solution yet, then this seems like the pragmatic thing to do for now. So yes, go for it.

Thank you.


Code cov

Codecov Report

:exclamation: No coverage uploaded for pull request base (main@9c23f5f). Click here to learn what that means.
Patch has no changes to coverable lines.

:mega: This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more
Additional details and impacted files
@@           Coverage Diff           @@
##             main      #19   +/-   ##
=======================================
  Coverage        ?   89.21%
=======================================
  Files           ?       21
  Lines           ?      408
  Branches        ?       73
=======================================
  Hits            ?      364
  Misses          ?       43
  Partials        ?        1

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


Change Recipe to use OreDictionary Entry of stick

I just tried to make the swapper and I saw that I cannot create it, using sticks from Natura. It is not a big problem, but I am just informing.

Will be fixed in the next update


add a package.json file

so we can install it using npm (you don't even need to really publish it, just add a file)

https://www.npmjs.com/package/selectize-plugin-clear

Added package.json, registered on npm


Update twitter card configuration

Twitter deprecated the 'photo' card and replaced it with the 'summary_large_image' card.
This pull request implements that new card; it also removes '/uploads' from robots.txt, since that was preventing the Twitterbot from finding the image inline.
(It also adds more metadata, such as the photo name and description.)
One note: there is a 'twitter:site' field, where you can put your twitter handle, and that way if you get hotlinked you get credit. I didn't see an easy way to tie that into settings, so I left it out.
p.s. I am not a dev, so I apologize if I did not do things The Best Way. But I tested it locally and it works, and I tried to follow existing styles. Thanks!

This PR will be closed because I'm not actively working on Lychee anymore. The repository of Lychee will stay available, but the main development continues under the Lychee Organisation. A fork maintained by the community.


Publish to f-droid app store or play store?

Could now download the APK files from the link mentioned. Easier if it is published to f-droid or google play store

The app is published on Google Play Store right here https://play.google.com/store/apps/details?id=com.netguru.babyguard


pull request for e2e test at 11/05/2016 07:56:02

:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

optest/docs/updated_at.md
:white_check_mark:Succeeded

Details

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


PAB <> Postgres (Beam Generalization)

Introduction
In this PR we generalize the beam database effect to support different SQL compliant backends. We have implemented an handler to connect to a postgres server and upgraded the existing sqlite handler to support this generalized effect. We have also adapted the pab as an example use of this upgrades. To pick which backend to use on the pab we can use the following snippets on the yaml configuration file:
SQLite:
# Configuration for an SQLite file
sqliteDB:
  dbConfigFile: pab-core.db
  dbConfigPoolSize: 20

Postgres:
# Configuration for a local postgres instance
postgresDB:
    dbConfigUser: postgres
    dbConfigPass: postgres123
    dbConfigHost: <IP_ADDRESS>
    dbConfigPort: 5432
    dbConfigDatabase: pab
    dbConfigPoolSize: 20

Implementation Details
The core of this generalization is on the module Control.Monad.Freer.Extras.Beam.Effect in here is the upgraded effect but unattached to the Sqlite backend. As denoted by its type declaration BeamEffect dbt r the database effect now takes a database type argument, dbt. Since the interface is the same as the old effect little adaptations were required on the pab side. The biggest change is the selection of the database backend handler which we currently do depending on the configuration file as noted in the introduction.
As it can be seen in the modules Control.Monad.Freer.Extras.Beam.Postgres and Control.Monad.Freer.Extras.Beam.Sqlite. The main difference between the backends is the connection and how the type is instanciated (either BeamEffect Postgres r or BeamEffect Sqlite r). This selection can be found in the module Plutus.PAB.App on the plutus-pab directory.
Checklist
Pre-submit checklist:

Branch

[ ] Tests are provided (if possible)
[x] Commit sequence broadly makes sense
[x] Key commits have useful messages
[x] Formatting, PNG optimization, etc. are updated

PR

[x] Self-reviewed the diff
[x] Useful pull request description
[ ] Reference the ADR in the PR and reference the PR in the ADR (if revelant)
[ ] Reviewer requested

Thanks for the review and comments @ak3n :) We will work on the suggestions.

The fundamental drawback of the current solution, to my taste, is the parametrization of BeamEffect with a database.

This is a really good point, but probably our main motivation for going for this implementation was trying not to change too much so we can have something more or less nice and working. Of course, if you have some interesting ideas we can discuss them :) In the meantime, we think that this feature is something useful to have right now. In fact, we are already using it on a couple of projects.

The whole point of using a database library like beam is the ability to switch the database in a seamless manner without changing the code. In the PR we would need to recompile the chain index to switch to postgresql. But it should be possible to change the database just by using a different configuration.

I agree that it would be great to change the chain-index db using a different configuration, but we didn't want to change the implementation too much, mostly considering the chain-index will be replaced with marconi (?)
In general, for us, the main motivation for adding postgresql was to solve some concurrency and throughput issues we were having with "Sqlite".

@ak3n would a merge with the main branch work?

Sure there you go!


Add missing space before links

Add missing space character before links and a few misc changes.

Thanks, @rageking8!


ci: debug git

to-be-reviewed @Lightning00Blade I will go one with testing this

Not sure what you mean by:

I will go one with testing this


clisops: subset-by-point

Extend the subset operation to support the proposed extension in: https://github.com/roocs/34e-mngmt/issues/105
Key issues:

level: allow x1/x2 and x1,x2,x3,x4
time: allow x1/x2 and x1,x2,x3,x4
year, month, day: add these arguments as options instead of time - either one or the other - if both: default to use time
how to distinguish between a range of (<start>, <end>) and a sequence of (<value1>, <value2>) - we need a way for our parser to know the difference - maybe work from rook downwards...rook will know if it is a range or a sequence, maybe the range is a special object rather than tuple!?

Updated implementation thoughts in clisops:
from clisops.ops import subset, time_interval, time_series, time_components

Even though they will actually be implemented in roocs-utils.
Example usage:
time_interval("2005-01-01T00:00:00", "2020-12-30T00:00:00")
time_series("2005-01-01T00:00:00", "2020-12-30T00:00:00")

# Implement the above but create an issue to discuss whether the naming is right!
# - could use "time_range" and "time_sequence" instead

time_components(year=[1999, 2000, 2001], month=[1, 2, 3], second=[0])
time_components(year=[1999, 2000, 2001], month=["jan", "Feb", "Mar"], second=[0])
# Note that month names work: "jan, feb, etc" (case-insensitive)

To-dos:

[x] Add tests for clisops.ops.subset
[ ] Add tests for clisops.core.subset


Create Open Loop Testing Phase: Tips & Lessons Learned

Per Dana's suggestion. Grammar error fixed.

Looks good, thanks for these tips @bpazoles


Update the Versions, Versions, Versions page

Currently, the Versions, Versions, Versions page lists the correct version of scalatestplus-play to use -- but the links to the ScalaDocs are messed up.  Specifically, all of the versions point to the 1.0.0 docs!  I just lost a fair while trying to figure out why my tests weren't working after upgrading to Play 2.4; eventually I realized it was because I was looking an antique and out-of-date Scaladoc, which didn't match the version 1.4.0 that I was actually using.
I'm now working around this by reading the Scaladoc comments directly in the source code, but it would help the community if these links got fixed...

Closing this.
The page is actually part of scalatest-website repository, as you can see here. Also, there is already a PR to add the most recent major version: scalatest/scalatest-website#55.


RKE Templates not visible in UI

I created some RKE templates but these are not visible:

However, when creating a cluster I can select the template from the drop down menu:

In FF Console there is this error: TypeError: this.clusterTemplate is null

Useful
Info

Versions
Rancher v2.3.3 UI: v2.3.25

Route
global-admin.cluster-templates.new

k8s Version
1.16.3

Browser
Firefox 70.0.1on macOS

Verified on Rancher v: 2.3.3, UI: v2.3.25 and Firefox v : 70.0.1. Not able to reproduce the issue.
Steps:

Create rke templates on the UI
User - Admin can see the available rke templates.
Create a cluster - DO, select  Use an existing RKE Template and revision.
User is able to select from created rke templates.
From Firefox browser, user is able to see the available rke templates.
Create a cluster - DO, select  Use an existing RKE Template and revision.  User is able to select from created rke templates.

Try creating a number of templates some being default and delete one. We also hit the same issue.

Some further info, that we've figured out, how this can get into this state, it seems somehow when deleting a clusterTemplate, clusterTemplateRevisions can be left behind, that then link to a not existent clusterTemplate. Annoyingly once you've found the offending clusterTemplateRevisions that cause the FE npe, you cannot even delete them by api, because it fails with 404 due to the link to the non existent clusterTemplate
cURL command line:
curl -u "${CATTLE_ACCESS_KEY}:${CATTLE_SECRET_KEY}"
-X DELETE
-H 'Accept: application/json'
'https://REDACTED/v3/clusterTemplateRevisions/cattle-global-data:ctr-4q2jk'
HTTP Request:
HTTP/1.1 DELETE /v3/clusterTemplateRevisions/cattle-global-data:ctr-4q2jk
Host: REDACTED
Accept: application/json
HTTP Response:
HTTP/1.1 404
content-encoding: gzip
content-length: 138
content-type: application/json
date: Tue, 03 Dec 2019 15:47:01 GMT
expires: Wed 24 Feb 1982 18:42:00 GMT
server: openresty/<IP_ADDRESS>
status: 404
strict-transport-security: max-age=15724800; includeSubDomains
x-api-schemas: https://REDACTED/v3/schemas
x-content-type-options: nosniff
{
"baseType": "error",
"code": "NotFound",
"message": "clustertemplates.management.cattle.io "ct-82tnz" not found",
"status": 404,
"type": "error"
}

As such it seems even by API its not possible to workaround this, and fix.

@michaelandrepearce Can you provide more information on how you are removing a cluster template?
From the issue I was able to pinpoint where the UI blows up and will resolve this, but there are mechanisms in place on the back-end that should clean up any cluster template revisions associated with a cluster template and I have not been able to reproduce the scenario you are describing.

If you wanted we could organise a screen share to show you the problem privately i cannot obviously share publically cluster details.

Re how we are removing it, it is via the UI.
it seems if you clean the revisions manually first (via api), before deleting the clustertemplate the issue can be avoided.
And a downgrade and upgrade of rancher (e.g. -> downgrade to 2.3.2 and re-upgrade to 2.3.3) clears the corrupt data in the server.

@michaelandrepearce I'm not sure I would be the right one to get on the share as the bug does seem to lie in the back-end cleanup mechanism. let me reach out to some other people and I'll circle back here when I have more info.

@michaelandrepearce @michaelpearce-gain Do you see this issue happen if you delete the clustertemplate (not revision) from the API?
Also for the clustertemplaterevisions that linger behind, do you see any finalizers present when you try to get the crd via kubectl? Also do you see ownerreferences set on those revisions?

Any news? I'm having the exact same issue. Deleted an old RKE Template, now UI is unable to display any templates. Error in Chrome console says -
clustertemplaterevision.js:25 Uncaught TypeError: Cannot read property 'defaultRevisionId' of null
    at n.<anonymous> (clustertemplaterevision.js:25)
    at n.a.get (metal.js:2984)
    at n.Object.defineProperty.get [as canMakeDefault] (metal.js:997)
    at n.<anonymous> (clustertemplaterevision.js:47)
    at n.a.get (metal.js:2984)
    at Object.ie [as get] (metal.js:1592)
    at n.<anonymous> (cattle-transitioning-resource.js:275)
    at n.a.get (metal.js:2984)
    at Object.ie [as get] (metal.js:1592)
    at component.js:221

Rancher version is v2.3.3.

@westlywright looks like there is another NPE in the UI from the logs that @davidweizheng posted above

@davidweizheng do you  think you can give the above UI fix a test by changing a global setting called ui-index for your rancher setup? You can find it via API at https:///v3/settings/ui-index

@michaelandrepearce works again in 2.3.4. Thanks

I ran into this issue when deleting a RKE Template on v2.3.5. It seems that deleting the template left behind the revision.
I fixed it by cleaning up etcd on Rancher itself.

I looked at /v3/clustertemplaterevisions on my browser to get the  name of the revision that was left behind. In this example ctr-d5s26 was the name of the revision left behind.
Ran etcdctl get --from-key '' | grep clustertemplaterevision | grep "ctr-d5s26" to find the key to delete.
Ran etcdctl del /registry/management.cattle.io/clustertemplaterevisions/cattle-global-data/ctr-d5s26 to delete the key in etcd.

Related to : https://github.com/rancher/rancher/issues/26861

Reproduced the issue in v2.3.3

Create 100 templates with 50 revisions in each .
Delete the templates

Some of the revisions are orphaned :
> kubectl get clustertemplaterevisions -n cattle-global-data
NAME        AGE
ctr-272cd   23m
ctr-2n9r7   21m
ctr-2zzjg   24m
ctr-4gpdq   20m
ctr-4gtmr   21m
ctr-5fvmj   25m
ctr-5h5sq   21m
ctr-5x2ds   24m
ctr-669xb   24m
ctr-66nqg   22m
ctr-68pvv   21m
ctr-6rwqc   24m
ctr-79r5b   24m
ctr-7h86w   23m
ctr-7pgvm   21m
ctr-85vqj   20m
ctr-9b4vw   22m
ctr-9nhwz   6m33s
ctr-bd7f7   24m
ctr-bjzcq   24m
ctr-bqmrw   23m
ctr-br94n   22m
ctr-c9bs4   24m
ctr-dbrxh   20m
ctr-f758k   23m
ctr-ftwmw   23m
ctr-gj5tn   23m
ctr-gljwd   23m
ctr-hll6h   21m

Create another rke template.
Navigate to the RKE templates page. The RKE templates page is empty

5. When we create a new cluster, the template is available to be selected

Tried the same steps as above in v2.4.4 and the issue is not observed. When there are revisions orphaned, the RKE templates are loaded in the UI as below. There was no error observed in the console.

Validated on v2.4-head.
Steps:

Create 200 templates with 50 revisions in each .
Delete the templates

There are no RKE revisions orphaned in the setup and the RKE templates are displayed correctly.


update fullnode release docs to clarify data wipe requirement

Description
Update the docs to consolidate some duplicate upgrade instructions for fullnodes. Also added clarification that wipes are only necessary for devnet
This was copied from:
https://github.com/aptos-labs/aptos-core/pull/11181
Checklist

[] Do all Lints pass?
[] Have you ran pnpm spellcheck?
[] Have you ran pnpm fmt?
[] Have you ran pnpm lint?

Current dependencies on/for this PR:

main

PR #18   👈

This stack of pull requests is managed by Graphite.

This looks strictly better than the previous, just please determine if release branches are needed for mainnet.


New lines not added to syntax tree + arbitrary fence character bug

I have been trying to use nvim treesitter to write a wrapper that is capable of interacting with R code and send it to a terminal. An issue I have run into is that lines of code that are added in the current R session do not appear in the treesitter playground. In addition, the index 0 fence character on line 58/9 in the video appears to not be a part of the syntax tree at all, while that same 0th character from other chunks (see: fence delimiter on line 48) does appear to be a part of the syntax tree.
https://user-images.githubusercontent.com/84149538/207265505-31343be1-4b03-4d60-8841-6eb6c7ed46d1.mp4
The former issue does not seem to have an effect on the actual correctness of my code, but the fence delimiter is causing issues. It is interpreted as nil by the treesitter utilities when it should not be. The following clip has me running a "send chunk" command on various parts of chunks. The nil bug only appears on the initial fence delimiter character on line 58 and not on the initial character in the chunk before (the issue then pops up at various other points throughout other parts of the code).
https://user-images.githubusercontent.com/84149538/207265667-81d1f7fb-4a39-4c2c-9570-9b30012a2622.mp4

I don't believe this is a tree-sitter-r issue


Implement Available class in C

This is a straight up port of the Available class to C with no attempts made to optimise the design.
I've tested that it produces an identical set of market books compared to the original Python code when reading one scraped Betfair prices file. It also (obviously) passes the tests.
I've used valgrind to check for any memory leaks or other incorrect object reference counting.
I still feel that the code would need to be tested much more comprehensively (i.e. on more price files across more machines) before it might be considered permanently replacing the Python implementation. An option could be that the user can choose whether to use this code at installation time e.g. pip install betfairlightweight[c].

Coverage decreased (-0.05%) to 94.963% when pulling fd2cfd3f600112fcf7ae9f688b20689752d96439 on mberk:cache-c-extension into 1af4115d5f7493a0b0b4dfb674987830b556464f on liampauling:master.

From a maintainability perspective, I wonder if writing the C-extension with Cython would be better as it doesn't require knowledge of the Python C-API and will handle implementation changes needed for updates to CPython. I'm not sure if you take a small performance hit using Cython vs hand written C code calling the C-API, but it's minimal if my memory is correct.

@synapticarbors are you on the betfairlightweight Slack? Are you aware of the background of this PR?

@mberk - I lurk over on the slack channel occasionally. I think you said that it was an experiment just to play around with the C-API, but correct me if I'm mistaken. I cloned your branch of this and tested it and didn't see any speed-up over the current pure python implementation, but I think in your testing you said there was a marginal speed-up. We may not be making the comparison in the same way. I'd be curious how you're benchmarking it.
I threw together a cython example, which had nearly identical performance, and basically required just a few lines of code change (e.g. cdef class Available vs class Available). I think it's really hard to beat the current implementation just by switching to the C-API since you're still dealing with python objects, so the best you can hope for is a maybe cutting a small bit of overhead. Typically when I use cython and get 10-1000x speed ups, it's for pure number crunching where you're looping over hundreds or thousands of elements of numpy arrays, or working with C structs/arrays instead of python objects. The real trick to cython or any similar strategy (numba, wrapping C code using the C-API directly, etc), is to minimize how often you cross the boundary between python and the low level machine code (where you avoid accessing the python c-api) and try to stay on the latter's side as long as possible to avoid the function call overhead from swamping the gains.

@synapticarbors, yes this was partly a learning exercise but the hope was that it would be a drop-in replacement that offered a meaningful boost in speed.
My initial testing showed the code read historic data in 83% of the time as the baseline which I would describe as better than marginal but now that I've put together some more concrete results to show you I am getting the same as you: the code is about the same as the pure Python class. Like you, I am not at all surprised by this as the number of function calls and objects created is the same.
For reference, this is what I am now using to test the speed:
import time

import betfairlightweight
from tqdm import tqdm
from tqdm import trange
from betfairlightweight import StreamListener

trading = betfairlightweight.APIClient("username", "password", "app_key")
listener = StreamListener(max_latency=None)
stream = trading.streaming.create_historical_generator_stream(
            file_path="/tmp/1.172557162",
                listener=listener,
                )
gen = stream.get_generator()
# Warmup
number_of_market_books = sum(1 for market_books in gen())
start_time = time.time()
for _ in trange(10):
    for market_books in tqdm(gen(), total=number_of_market_books):
        pass
print(time.time() - start_time)

I'm open to ideas from everyone on the best way to benchmark any potential performance improvements as I believe having a good, agreed-upon benchmark is an important starting point.

Thanks for the concrete code. I was just running examples from the test suite using timeit (in a jupyter-lab notebook). So for example, things like:
current = [[27, 0.95], [13, 28.01], [1.02, 1157.21]]
%timeit available = Available(current, 1)

or
book_update = [[30, 6.9], [1.01, 12]]
current = [[27, 0.95], [13, 28.01], [1.02, 1157.21]]
available = Available(current, 1)
%timeit available.update(book_update)

This was just to get at how much time creation of the object and updating the object took comparatively using each implementation (python, c-api, cython). Certainly this is a microbenchmark and repeatedly calling update on the same object with the same data isn't ideal, but I was just trying to get a feel for any stark differences (you can always call %timeit -n1 -r1 available.update(book_update) to call it once, which I also played around with).
While I like your benchmark for trying to see if there is a change in real world performance on, I didn't have a good sense of how much time creation and updating the Available object took as a fraction of the whole workload, and whether it would be easy to detect small changes against the background of variability in all of the other functions that are being called. I think there's validity in doing these system level benchmarks as well as microbenchmarks of individual functionalities.

A fair comment that my benchmark is not isolating the code but my starting point was this comment from @liampauling on Slack:

Having profiled (a lot) over the years I know the Available class is the bottleneck, contemplating a rewrite in C...

Closing, refactor in 2.12 meets current demands.


[helpers] Organization membership related methods #107

Closes #107

Coverage increased (+0.01%) to 96.724% when pulling 514cf0b01ad6ad668ebaedd74ada4514e496933d on 107-org-membership into 8096706dd5d8acd2dd8ed663ac165d7dc43074d9 on master.


Failed to start flynn-host.service: Unit flynn-host.service not found.

install flynn
sudo bash < <(curl -fsSL https://dl.flynn.io/install-flynn)
also did
sudo flynn-host update
Tried running
sudo systemctl start flynn-host
Outputs
Failed to start flynn-host.service: Unit flynn-host.service not found.
Also did
sudo start flynn-host
and it output
Unable to connect to Upstart: Failed to connect to socket /com/ubuntu/upstart: Connection refused
So now am so confused. Like I want to uninstall it and try installing it again.
But don't know how.

@connelevalsam did you get any errors when you ran the install script?
Please run the following and put the full output in a gist so we can see what happens:
$ curl -fsSL -o /tmp/install-flynn https://dl.flynn.io/install-flynn
$ sudo bash /tmp/install-flynn --clean

Thanks @lmars here's the gist:
https://gist.github.com/connelevalsam/47998a29016c65ce7ff2ee05a029f196

@connelevalsam The error in the log you posted has been fixed (#4186), please try again and post a new full log if it fails.

@titanous thanks for your reply, are you saying I should install flynn again?

@connelevalsam yes try installing from clean again.

Flynn is unmaintained and our infrastructure will shut down on June 1, 2021. See the README for details.


geo distance sort

Hello, I have installed this package successfully and all is working fine. For 2 days I am wondering and trying to sort my results by "_geo_distance" how can I do this? Thank you for the time in advance!!!
by the way,the Official document do it like this

Hi @MutionHu, currently only simple sorting is supported (you can specify a field and a sort direction). You can use the searchRaw method, but be aware, that you will give you a raw response from ES.


Approving changes does NOT fully invalidate Cloudfront cache

This issue is similar to https://github.com/mozilla-services/remote-settings-lambdas/issues/46 in the sense that validate_signature lambda keeps failing until we manually run refresh_signature lambda.
What happened was at 8:55am PDT someone approved some changes on staging/certificates collection, and afterwards the validate_signature lambda started to fail and paged operations. We had to log in and manually run refresh_signature lambda to correct it.
The validate_signature lambda error looks like this:
Signature verification failed on /buckets/blocklists/collections/certificates
- Signed on:<PHONE_NUMBER>885 (2018-12-14 16:55:48 UTC)
- Records timestamp:<PHONE_NUMBER>803 (2018-11-02 18:49:40 UTC): ValidationError
Traceback (most recent call last):
File "/var/task/aws_lambda.py", line 139, in validate_signature
raise ValidationError("\n" + "\n\n".join(error_messages))
aws_lambda.ValidationError:
Signature verification failed on /buckets/blocklists/collections/certificates
- Signed on:<PHONE_NUMBER>885 (2018-12-14 16:55:48 UTC)
- Records timestamp:<PHONE_NUMBER>803 (2018-11-02 18:49:40 UTC)

Looking at kinto-writer's log, the application seemed to have tried to invalidate the cloudfront cache.
Dec 14 16:55:49 ip-172-31-10-135 docker-kinto[2604]: {"Timestamp":<PHONE_NUMBER>341082624, "Type": "kinto_signer.updater", "Logger": "kinto", "Hostname": "ip-172-31-10-135.us-west-2.compute.internal", "EnvVersion": "2.0", "Severity": 6, "Pid": 48, "Fields": {"msg": "Invalidated CloudFront cache at /v1/*"}}
Dec 14 16:55:49 ip-172-31-10-135 docker-kinto[2604]: {"Timestamp":<PHONE_NUMBER>360110848, "Type": "kinto_megaphone.listeners", "Logger": "kinto", "Hostname": "ip-172-31-10-135.us-west-2.compute.internal", "EnvVersion": "2.0", "Severity": 6, "Pid": 48, "Fields": {"msg": "Sending version: remote-settings, monitor_changes"}}
Dec 14 16:55:49 ip-172-31-10-135 docker-kinto[2604]: {"Timestamp":<PHONE_NUMBER>442699520, "Type": "kinto_megaphone.megaphone", "Logger": "kinto", "Hostname": "ip-172-31-10-135.us-west-2.compute.internal", "EnvVersion": "2.0", "Severity": 6, "Pid": 48, "Fields": {"msg": "Sent version to megaphone. Response was 200"}}
Dec 14 16:55:52 ip-172-31-10-135 docker-kinto[2604]: {"Timestamp":<PHONE_NUMBER>562391296, "Type": "subrequest.summary", "Logger": "kinto", "Hostname": "ip-172-31-10-135.us-west-2.compute.internal", "EnvVersion": "2.0", "Severity": 6, "Pid": 44, "Fields": {"agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:66.0) Gecko/20100101 Firefox/66.0", "path": "/v1/buckets/staging/collections/certificates", "method": "GET", "lang": "en-US,en;q=0.5", "errno": 0, "batch_size": 3, "
Dec 14 16:55:52 ip-172-31-10-135 docker-kinto[2604]: {"Timestamp":<PHONE_NUMBER>618742528, "Type": "subrequest.summary", "Logger": "kinto", "Hostname": "ip-172-31-10-135.us-west-2.compute.internal", "EnvVersion": "2.0", "Severity": 6, "Pid": 44, "Fields": {"agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:66.0) Gecko/20100101 Firefox/66.0", "path": "/v1/buckets/blocklists-preview/collections/certificates", "method": "GET", "lang": "en-US,en;q=0.5", "errno": 0, "batch_
Dec 14 16:55:52 ip-172-31-10-135 docker-kinto[2604]: {"Timestamp":<PHONE_NUMBER>684661760, "Type": "subrequest.summary", "Logger": "kinto", "Hostname": "ip-172-31-10-135.us-west-2.compute.internal", "EnvVersion": "2.0", "Severity": 6, "Pid": 44, "Fields": {"agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:66.0) Gecko/20100101 Firefox/66.0", "path": "/v1/buckets/blocklists/collections/certificates", "method": "GET", "lang": "en-US,en;q=0.5", "errno": 0, "batch_size": 3

However, we suspect it didn't invalidate what needed to be invalidated because not only validate_signature lambda started to fail after 8:55am PDT, but in the Cloudfront invalidation logs, we only see one invalidation request, whereas when we manually triggered refresh_signature lambda, it triggered much more invalidation requests, like below,
Dec 14 17:53:58 ip-172-31-10-135 docker-kinto[2604]: {"Timestamp":<PHONE_NUMBER>524194048, "Type": "kinto_signer.updater", "Logger": "kinto", "Hostname": "ip-172-31-10-135.us-west-2.compute.internal", "EnvVersion": "2.0", "Severity": 6, "Pid": 47, "Fields": {"msg": "Invalidated CloudFront cache at /v1/*"}}
Dec 14 17:53:59 ip-172-31-10-135 docker-kinto[2604]: {"Timestamp":<PHONE_NUMBER>192479744, "Type": "kinto_signer.updater", "Logger": "kinto", "Hostname": "ip-172-31-10-135.us-west-2.compute.internal", "EnvVersion": "2.0", "Severity": 6, "Pid": 47, "Fields": {"msg": "Invalidated CloudFront cache at /v1/*"}}
Dec 14 17:53:59 ip-172-31-10-135 docker-kinto[2604]: {"Timestamp":<PHONE_NUMBER>542577408, "Type": "kinto.core.storage.postgresql.pool.QueuePoolWithMaxBacklog", "Logger": "kinto", "Hostname": "ip-172-31-10-135.us-west-2.compute.internal", "EnvVersion": "2.0", "Severity": 6, "Pid": 48, "Fields": {"msg": "Connection <connection object at 0x7fb211358e88; dsn: 'user=kinto password=xxx dbname=kinto host=kinto-rds-prod.ctwh8irpumru.us-west-2.rds.amazonaws.com port=5432', closed: 0> exceeded timeout; recycling"}}
Dec 14 17:54:00 ip-172-31-10-135 docker-kinto[2604]: {"Timestamp":<PHONE_NUMBER>259059456, "Type": "kinto_signer.updater", "Logger": "kinto", "Hostname": "ip-172-31-10-135.us-west-2.compute.internal", "EnvVersion": "2.0", "Severity": 6, "Pid": 48, "Fields": {"msg": "Invalidated CloudFront cache at /v1/*"}}
Dec 14 17:54:00 ip-172-31-10-135 docker-kinto[2604]: {"Timestamp":<PHONE_NUMBER>953859584, "Type": "kinto_signer.updater", "Logger": "kinto", "Hostname": "ip-172-31-10-135.us-west-2.compute.internal", "EnvVersion": "2.0", "Severity": 6, "Pid": 48, "Fields": {"msg": "Invalidated CloudFront cache at /v1/*"}}
Dec 14 17:54:01 ip-172-31-10-135 docker-kinto[2604]: {"Timestamp":<PHONE_NUMBER>959233536, "Type": "kinto_signer.updater", "Logger": "kinto", "Hostname": "ip-172-31-10-135.us-west-2.compute.internal", "EnvVersion": "2.0", "Severity": 6, "Pid": 44, "Fields": {"msg": "Invalidated CloudFront cache at /v1/*"}}
Dec 14 17:54:02 ip-172-31-10-135 docker-kinto[2604]: {"Timestamp":<PHONE_NUMBER>443594496, "Type": "kinto_signer.updater", "Logger": "kinto", "Hostname": "ip-172-31-10-135.us-west-2.compute.internal", "EnvVersion": "2.0", "Severity": 6, "Pid": 44, "Fields": {"msg": "Invalidated CloudFront cache at /v1/*"}}
Dec 14 17:54:03 ip-172-31-10-135 docker-kinto[2604]: {"Timestamp":<PHONE_NUMBER>468941312, "Type": "kinto_signer.updater", "Logger": "kinto", "Hostname": "ip-172-31-10-135.us-west-2.compute.internal", "EnvVersion": "2.0", "Severity": 6, "Pid": 48, "Fields": {"msg": "Invalidated CloudFront cache at /v1/*"}}
Dec 14 17:54:03 ip-172-31-10-135 docker-kinto[2604]: {"Timestamp":<PHONE_NUMBER>936243968, "Type": "kinto_signer.updater", "Logger": "kinto", "Hostname": "ip-172-31-10-135.us-west-2.compute.internal", "EnvVersion": "2.0", "Severity": 6, "Pid": 48, "Fields": {"msg": "Invalidated CloudFront cache at /v1/*"}}
Dec 14 17:54:05 ip-172-31-10-135 docker-kinto[2604]: {"Timestamp":<PHONE_NUMBER>060901632, "Type": "kinto_signer.updater", "Logger": "kinto", "Hostname": "ip-172-31-10-135.us-west-2.compute.internal", "EnvVersion": "2.0", "Severity": 6, "Pid": 48, "Fields": {"msg": "Invalidated CloudFront cache at /v1/*"}}
Dec 14 17:54:05 ip-172-31-10-135 docker-kinto[2604]: {"Timestamp":<PHONE_NUMBER>717103360, "Type": "kinto_signer.updater", "Logger": "kinto", "Hostname": "ip-172-31-10-135.us-west-2.compute.internal", "EnvVersion": "2.0", "Severity": 6, "Pid": 48, "Fields": {"msg": "Invalidated CloudFront cache at /v1/*"}}
Dec 14 17:54:06 ip-172-31-10-135 docker-kinto[2604]: {"Timestamp":<PHONE_NUMBER>769856000, "Type": "kinto_signer.updater", "Logger": "kinto", "Hostname": "ip-172-31-10-135.us-west-2.compute.internal", "EnvVersion": "2.0", "Severity": 6, "Pid": 44, "Fields": {"msg": "Invalidated CloudFront cache at /v1/*"}}
Dec 14 17:54:07 ip-172-31-10-135 docker-kinto[2604]: {"Timestamp":<PHONE_NUMBER>303014656, "Type": "kinto_signer.updater", "Logger": "kinto", "Hostname": "ip-172-31-10-135.us-west-2.compute.internal", "EnvVersion": "2.0", "Severity": 6, "Pid": 44, "Fields": {"msg": "Invalidated CloudFront cache at /v1/*"}}
Dec 14 17:54:08 ip-172-31-10-135 docker-kinto[2604]: {"Timestamp":<PHONE_NUMBER>370542592, "Type": "kinto_signer.updater", "Logger": "kinto", "Hostname": "ip-172-31-10-135.us-west-2.compute.internal", "EnvVersion": "2.0", "Severity": 6, "Pid": 47, "Fields": {"msg": "Invalidated CloudFront cache at /v1/*"}}
Dec 14 17:54:08 ip-172-31-10-135 docker-kinto[2604]: {"Timestamp":<PHONE_NUMBER>814711296, "Type": "kinto_signer.updater", "Logger": "kinto", "Hostname": "ip-172-31-10-135.us-west-2.compute.internal", "EnvVersion": "2.0", "Severity": 6, "Pid": 47, "Fields": {"msg": "Invalidated CloudFront cache at /v1/*"}}
Dec 14 17:54:09 ip-172-31-10-135 docker-kinto[2604]: {"Timestamp":<PHONE_NUMBER>901712128, "Type": "kinto_signer.updater", "Logger": "kinto", "Hostname": "ip-172-31-10-135.us-west-2.compute.internal", "EnvVersion": "2.0", "Severity": 6, "Pid": 48, "Fields": {"msg": "Invalidated CloudFront cache at /v1/*"}}
Dec 14 17:54:10 ip-172-31-10-135 docker-kinto[2604]: {"Timestamp":<PHONE_NUMBER>473050112, "Type": "kinto_signer.updater", "Logger": "kinto", "Hostname": "ip-172-31-10-135.us-west-2.compute.internal", "EnvVersion": "2.0", "Severity": 3, "Pid": 48, "Fields": {"msg": "Cache invalidation request failed.", "error": "TooManyInvalidationsInProgress('An error occurred (TooManyInvalidationsInProgress) when calling the CreateInvalidation operation: Processing your request will cause you to exceed the maximum number of in-progress wildcard invalidations.')", "traceback": "Uncaught exception:\n  File \"/usr/local/lib/python3.7/site-packages/kinto_signer/updater.py\", line 405, in invalidate_cloudfront_cache\n    'CallerReference': '{}-{}'.format(timestamp, uuid.uuid4())\n  File \"/usr/local/lib/python3.7/site-packages/botocore/client.py\", line 320, in _api_call\n    return self._make_api_call(operation_name, kwargs)\n  File \"/usr/local/lib/python3.7/site-packages/botocore/client.py\", line 623, in _make_api_call\n    raise error_class(parsed_response, operation_name)\n<class 'botocore.errorfactory.TooManyInvalidationsInProgress'>\nTooManyInvalidationsInProgress('An error occurred (TooManyInvalidationsInProgress) when calling the CreateInvalidation operation: Processing your request will cause you to exceed the maximum number of in-progress wildcard invalidations.')\n"}}
Dec 14 17:54:11 ip-172-31-10-135 docker-kinto[2604]: [busyness] worker nr 6 30s average busyness is at 8%
Dec 14 17:54:11 ip-172-31-10-135 docker-kinto[2604]: [busyness] worker nr 7 30s average busyness is at 8%
Dec 14 17:54:11 ip-172-31-10-135 docker-kinto[2604]: [busyness] worker nr 8 30s average busyness is at 17%
Dec 14 17:54:11 ip-172-31-10-135 docker-kinto[2604]: [busyness] 30s average busyness of 3 worker(s) is at 11%
Dec 14 17:54:11 ip-172-31-10-135 docker-kinto[2604]: {"Timestamp":<PHONE_NUMBER>535116800, "Type": "kinto_signer.updater", "Logger": "kinto", "Hostname": "ip-172-31-10-135.us-west-2.compute.internal", "EnvVersion": "2.0", "Severity": 3, "Pid": 48, "Fields": {"msg": "Cache invalidation request failed.", "error": "TooManyInvalidationsInProgress('An error occurred (TooManyInvalidationsInProgress) when calling the CreateInvalidation operation: Processing your request will cause you to exceed the maximum number of in-progress wildcard invalidations.')", "traceback": "Uncaught exception:\n  File \"/usr/local/lib/python3.7/site-packages/kinto_signer/updater.py\", line 405, in invalidate_cloudfront_cache\n    'CallerReference': '{}-{}'.format(timestamp, uuid.uuid4())\n  File \"/usr/local/lib/python3.7/site-packages/botocore/client.py\", line 320, in _api_call\n    return self._make_api_call(operation_name, kwargs)\n  File \"/usr/local/lib/python3.7/site-packages/botocore/client.py\", line 623, in _make_api_call\n    raise error_class(parsed_response, operation_name)\n<class 'botocore.errorfactory.TooManyInvalidationsInProgress'>\nTooManyInvalidationsInProgress('An error occurred (TooManyInvalidationsInProgress) when calling the CreateInvalidation operation: Processing your request will cause you to exceed the maximum number of in-progress wildcard invalidations.')\n"}}
Dec 14 17:54:11 ip-172-31-10-135 docker-kinto[2604]: {"Timestamp":<PHONE_NUMBER>976226048, "Type": "kinto_signer.updater", "Logger": "kinto", "Hostname": "ip-172-31-10-135.us-west-2.compute.internal", "EnvVersion": "2.0", "Severity": 3, "Pid": 48, "Fields": {"msg": "Cache invalidation request failed.", "error": "TooManyInvalidationsInProgress('An error occurred (TooManyInvalidationsInProgress) when calling the CreateInvalidation operation: Processing your request will cause you to exceed the maximum number of in-progress wildcard invalidations.')", "traceback": "Uncaught exception:\n  File \"/usr/local/lib/python3.7/site-packages/kinto_signer/updater.py\", line 405, in invalidate_cloudfront_cache\n    'CallerReference': '{}-{}'.format(timestamp, uuid.uuid4())\n  File \"/usr/local/lib/python3.7/site-packages/botocore/client.py\", line 320, in _api_call\n    return self._make_api_call(operation_name, kwargs)\n  File \"/usr/local/lib/python3.7/site-packages/botocore/client.py\", line 623, in _make_api_call\n    raise error_class(parsed_response, operation_name)\n<class 'botocore.errorfactory.TooManyInvalidationsInProgress'>\nTooManyInvalidationsInProgress('An error occurred (TooManyInvalidationsInProgress) when calling the CreateInvalidation operation: Processing your request will cause you to exceed the maximum number of in-progress wildcard invalidations.')\n"}}
Dec 14 17:54:13 ip-172-31-10-135 docker-kinto[2604]: {"Timestamp":<PHONE_NUMBER>193980160, "Type": "kinto_signer.updater", "Logger": "kinto", "Hostname": "ip-172-31-10-135.us-west-2.compute.internal", "EnvVersion": "2.0", "Severity": 3, "Pid": 48, "Fields": {"msg": "Cache invalidation request failed.", "error": "TooManyInvalidationsInProgress('An error occurred (TooManyInvalidationsInProgress) when calling the CreateInvalidation operation: Processing your request will cause you to exceed the maximum number of in-progress wildcard invalidations.')", "traceback": "Uncaught exception:\n  File \"/usr/local/lib/python3.7/site-packages/kinto_signer/updater.py\", line 405, in invalidate_cloudfront_cache\n    'CallerReference': '{}-{}'.format(timestamp, uuid.uuid4())\n  File \"/usr/local/lib/python3.7/site-packages/botocore/client.py\", line 320, in _api_call\n    return self._make_api_call(operation_name, kwargs)\n  File \"/usr/local/lib/python3.7/site-packages/botocore/client.py\", line 623, in _make_api_call\n    raise error_class(parsed_response, operation_name)\n<class 'botocore.errorfactory.TooManyInvalidationsInProgress'>\nTooManyInvalidationsInProgress('An error occurred (TooManyInvalidationsInProgress) when calling the CreateInvalidation operation: Processing your request will cause you to exceed the maximum number of in-progress wildcard invalidations.')\n"}}
Dec 14 17:54:13 ip-172-31-10-135 docker-kinto[2604]: {"Timestamp":<PHONE_NUMBER>642588160, "Type": "kinto_signer.updater", "Logger": "kinto", "Hostname": "ip-172-31-10-135.us-west-2.compute.internal", "EnvVersion": "2.0", "Severity": 3, "Pid": 48, "Fields": {"msg": "Cache invalidation request failed.", "error": "TooManyInvalidationsInProgress('An error occurred (TooManyInvalidationsInProgress) when calling the CreateInvalidation operation: Processing your request will cause you to exceed the maximum number of in-progress wildcard invalidations.')", "traceback": "Uncaught exception:\n  File \"/usr/local/lib/python3.7/site-packages/kinto_signer/updater.py\", line 405, in invalidate_cloudfront_cache\n    'CallerReference': '{}-{}'.format(timestamp, uuid.uuid4())\n  File \"/usr/local/lib/python3.7/site-packages/botocore/client.py\", line 320, in _api_call\n    return self._make_api_call(operation_name, kwargs)\n  File \"/usr/local/lib/python3.7/site-packages/botocore/client.py\", line 623, in _make_api_call\n    raise error_class(parsed_response, operation_name)\n<class 'botocore.errorfactory.TooManyInvalidationsInProgress'>\nTooManyInvalidationsInProgress('An error occurred (TooManyInvalidationsInProgress) when calling the CreateInvalidation operation: Processing your request will cause you to exceed the maximum number of in-progress wildcard invalidations.')\n"}}
Dec 14 17:54:14 ip-172-31-10-135 docker-kinto[2604]: {"Timestamp":<PHONE_NUMBER>826879488, "Type": "kinto_signer.updater", "Logger": "kinto", "Hostname": "ip-172-31-10-135.us-west-2.compute.internal", "EnvVersion": "2.0", "Severity": 3, "Pid": 44, "Fields": {"msg": "Cache invalidation request failed.", "error": "TooManyInvalidationsInProgress('An error occurred (TooManyInvalidationsInProgress) when calling the CreateInvalidation operation: Processing your request will cause you to exceed the maximum number of in-progress wildcard invalidations.')", "traceback": "Uncaught exception:\n  File \"/usr/local/lib/python3.7/site-packages/kinto_signer/updater.py\", line 405, in invalidate_cloudfront_cache\n    'CallerReference': '{}-{}'.format(timestamp, uuid.uuid4())\n  File \"/usr/local/lib/python3.7/site-packages/botocore/client.py\", line 320, in _api_call\n    return self._make_api_call(operation_name, kwargs)\n  File \"/usr/local/lib/python3.7/site-packages/botocore/client.py\", line 623, in _make_api_call\n    raise error_class(parsed_response, operation_name)\n<class 'botocore.errorfactory.TooManyInvalidationsInProgress'>\nTooManyInvalidationsInProgress('An error occurred (TooManyInvalidationsInProgress) when calling the CreateInvalidation operation: Processing your request will cause you to exceed the maximum number of in-progress wildcard invalidations.')\n"}}
Dec 14 17:54:15 ip-172-31-10-135 docker-kinto[2604]: {"Timestamp":<PHONE_NUMBER>273828608, "Type": "kinto_signer.updater", "Logger": "kinto", "Hostname": "ip-172-31-10-135.us-west-2.compute.internal", "EnvVersion": "2.0", "Severity": 3, "Pid": 44, "Fields": {"msg": "Cache invalidation request failed.", "error": "TooManyInvalidationsInProgress('An error occurred (TooManyInvalidationsInProgress) when calling the CreateInvalidation operation: Processing your request will cause you to exceed the maximum number of in-progress wildcard invalidations.')", "traceback": "Uncaught exception:\n  File \"/usr/local/lib/python3.7/site-packages/kinto_signer/updater.py\", line 405, in invalidate_cloudfront_cache\n    'CallerReference': '{}-{}'.format(timestamp, uuid.uuid4())\n  File \"/usr/local/lib/python3.7/site-packages/botocore/client.py\", line 320, in _api_call\n    return self._make_api_call(operation_name, kwargs)\n  File \"/usr/local/lib/python3.7/site-packages/botocore/client.py\", line 623, in _make_api_call\n    raise error_class(parsed_response, operation_name)\n<class 'botocore.errorfactory.TooManyInvalidationsInProgress'>\nTooManyInvalidationsInProgress('An error occurred (TooManyInvalidationsInProgress) when calling the CreateInvalidation operation: Processing your request will cause you to exceed the maximum number of in-progress wildcard invalidations.')\n"}}
Dec 14 17:54:16 ip-172-31-10-135 docker-kinto[2604]: {"Timestamp":<PHONE_NUMBER>593531648, "Type": "kinto_signer.updater", "Logger": "kinto", "Hostname": "ip-172-31-10-135.us-west-2.compute.internal", "EnvVersion": "2.0", "Severity": 3, "Pid": 47, "Fields": {"msg": "Cache invalidation request failed.", "error": "TooManyInvalidationsInProgress('An error occurred (TooManyInvalidationsInProgress) when calling the CreateInvalidation operation: Processing your request will cause you to exceed the maximum number of in-progress wildcard invalidations.')", "traceback": "Uncaught exception:\n  File \"/usr/local/lib/python3.7/site-packages/kinto_signer/updater.py\", line 405, in invalidate_cloudfront_cache\n    'CallerReference': '{}-{}'.format(timestamp, uuid.uuid4())\n  File \"/usr/local/lib/python3.7/site-packages/botocore/client.py\", line 320, in _api_call\n    return self._make_api_call(operation_name, kwargs)\n  File \"/usr/local/lib/python3.7/site-packages/botocore/client.py\", line 623, in _make_api_call\n    raise error_class(parsed_response, operation_name)\n<class 'botocore.errorfactory.TooManyInvalidationsInProgress'>\nTooManyInvalidationsInProgress('An error occurred (TooManyInvalidationsInProgress) when calling the CreateInvalidation operation: Processing your request will cause you to exceed the maximum number of in-progress wildcard invalidations.')\n"}}
Dec 14 17:54:17 ip-172-31-10-135 docker-kinto[2604]: {"Timestamp":<PHONE_NUMBER>052123648, "Type": "kinto_signer.updater", "Logger": "kinto", "Hostname": "ip-172-31-10-135.us-west-2.compute.internal", "EnvVersion": "2.0", "Severity": 3, "Pid": 47, "Fields": {"msg": "Cache invalidation request failed.", "error": "TooManyInvalidationsInProgress('An error occurred (TooManyInvalidationsInProgress) when calling the CreateInvalidation operation: Processing your request will cause you to exceed the maximum number of in-progress wildcard invalidations.')", "traceback": "Uncaught exception:\n  File \"/usr/local/lib/python3.7/site-packages/kinto_signer/updater.py\", line 405, in invalidate_cloudfront_cache\n    'CallerReference': '{}-{}'.format(timestamp, uuid.uuid4())\n  File \"/usr/local/lib/python3.7/site-packages/botocore/client.py\", line 320, in _api_call\n    return self._make_api_call(operation_name, kwargs)\n  File \"/usr/local/lib/python3.7/site-packages/botocore/client.py\", line 623, in _make_api_call\n    raise error_class(parsed_response, operation_name)\n<class 'botocore.errorfactory.TooManyInvalidationsInProgress'>\nTooManyInvalidationsInProgress('An error occurred (TooManyInvalidationsInProgress) when calling the CreateInvalidation operation: Processing your request will cause you to exceed the maximum number of in-progress wildcard invalidations.')\n"}}
Dec 14 17:54:18 ip-172-31-10-135 docker-kinto[2604]: {"Timestamp":<PHONE_NUMBER>332531456, "Type": "kinto_signer.updater", "Logger": "kinto", "Hostname": "ip-172-31-10-135.us-west-2.compute.internal", "EnvVersion": "2.0", "Severity": 3, "Pid": 47, "Fields": {"msg": "Cache invalidation request failed.", "error": "TooManyInvalidationsInProgress('An error occurred (TooManyInvalidationsInProgress) when calling the CreateInvalidation operation: Processing your request will cause you to exceed the maximum number of in-progress wildcard invalidations.')", "traceback": "Uncaught exception:\n  File \"/usr/local/lib/python3.7/site-packages/kinto_signer/updater.py\", line 405, in invalidate_cloudfront_cache\n    'CallerReference': '{}-{}'.format(timestamp, uuid.uuid4())\n  File \"/usr/local/lib/python3.7/site-packages/botocore/client.py\", line 320, in _api_call\n    return self._make_api_call(operation_name, kwargs)\n  File \"/usr/local/lib/python3.7/site-packages/botocore/client.py\", line 623, in _make_api_call\n    raise error_class(parsed_response, operation_name)\n<class 'botocore.errorfactory.TooManyInvalidationsInProgress'>\nTooManyInvalidationsInProgress('An error occurred (TooManyInvalidationsInProgress) when calling the CreateInvalidation operation: Processing your request will cause you to exceed the maximum number of in-progress wildcard invalidations.')\n"}}
Dec 14 17:54:18 ip-172-31-10-135 docker-kinto[2604]: {"Timestamp":<PHONE_NUMBER>893177856, "Type": "kinto_signer.updater", "Logger": "kinto", "Hostname": "ip-172-31-10-135.us-west-2.compute.internal", "EnvVersion": "2.0", "Severity": 3, "Pid": 47, "Fields": {"msg": "Cache invalidation request failed.", "error": "TooManyInvalidationsInProgress('An error occurred (TooManyInvalidationsInProgress) when calling the CreateInvalidation operation: Processing your request will cause you to exceed the maximum number of in-progress wildcard invalidations.')", "traceback": "Uncaught exception:\n  File \"/usr/local/lib/python3.7/site-packages/kinto_signer/updater.py\", line 405, in invalidate_cloudfront_cache\n    'CallerReference': '{}-{}'.format(timestamp, uuid.uuid4())\n  File \"/usr/local/lib/python3.7/site-packages/botocore/client.py\", line 320, in _api_call\n    return self._make_api_call(operation_name, kwargs)\n  File \"/usr/local/lib/python3.7/site-packages/botocore/client.py\", line 623, in _make_api_call\n    raise error_class(parsed_response, operation_name)\n<class 'botocore.errorfactory.TooManyInvalidationsInProgress'>\nTooManyInvalidationsInProgress('An error occurred (TooManyInvalidationsInProgress) when calling the CreateInvalidation operation: Processing your request will cause you to exceed the maximum number of in-progress wildcard invalidations.')\n"}}
Dec 14 17:54:20 ip-172-31-10-135 docker-kinto[2604]: {"Timestamp":<PHONE_NUMBER>085889024, "Type": "kinto_signer.updater", "Logger": "kinto", "Hostname": "ip-172-31-10-135.us-west-2.compute.internal", "EnvVersion": "2.0", "Severity": 3, "Pid": 47, "Fields": {"msg": "Cache invalidation request failed.", "error": "TooManyInvalidationsInProgress('An error occurred (TooManyInvalidationsInProgress) when calling the CreateInvalidation operation: Processing your request will cause you to exceed the maximum number of in-progress wildcard invalidations.')", "traceback": "Uncaught exception:\n  File \"/usr/local/lib/python3.7/site-packages/kinto_signer/updater.py\", line 405, in invalidate_cloudfront_cache\n    'CallerReference': '{}-{}'.format(timestamp, uuid.uuid4())\n  File \"/usr/local/lib/python3.7/site-packages/botocore/client.py\", line 320, in _api_call\n    return self._make_api_call(operation_name, kwargs)\n  File \"/usr/local/lib/python3.7/site-packages/botocore/client.py\", line 623, in _make_api_call\n    raise error_class(parsed_response, operation_name)\n<class 'botocore.errorfactory.TooManyInvalidationsInProgress'>\nTooManyInvalidationsInProgress('An error occurred (TooManyInvalidationsInProgress) when calling the CreateInvalidation operation: Processing your request will cause you to exceed the maximum number of in-progress wildcard invalidations.')\n"}}
Dec 14 17:54:20 ip-172-31-10-135 docker-kinto[2604]: {"Timestamp":<PHONE_NUMBER>551599104, "Type": "kinto_signer.updater", "Logger": "kinto", "Hostname": "ip-172-31-10-135.us-west-2.compute.internal", "EnvVersion": "2.0", "Severity": 3, "Pid": 47, "Fields": {"msg": "Cache invalidation request failed.", "error": "TooManyInvalidationsInProgress('An error occurred (TooManyInvalidationsInProgress) when calling the CreateInvalidation operation: Processing your request will cause you to exceed the maximum number of in-progress wildcard invalidations.')", "traceback": "Uncaught exception:\n  File \"/usr/local/lib/python3.7/site-packages/kinto_signer/updater.py\", line 405, in invalidate_cloudfront_cache\n    'CallerReference': '{}-{}'.format(timestamp, uuid.uuid4())\n  File \"/usr/local/lib/python3.7/site-packages/botocore/client.py\", line 320, in _api_call\n    return self._make_api_call(operation_name, kwargs)\n  File \"/usr/local/lib/python3.7/site-packages/botocore/client.py\", line 623, in _make_api_call\n    raise error_class(parsed_response, operation_name)\n<class 'botocore.errorfactory.TooManyInvalidationsInProgress'>\nTooManyInvalidationsInProgress('An error occurred (TooManyInvalidationsInProgress) when calling the CreateInvalidation operation: Processing your request will cause you to exceed the maximum number of in-progress wildcard invalidations.')\n"}}
Dec 14 17:54:21 ip-172-31-10-135 docker-kinto[2604]: {"Timestamp":<PHONE_NUMBER>741596928, "Type": "kinto_signer.updater", "Logger": "kinto", "Hostname": "ip-172-31-10-135.us-west-2.compute.internal", "EnvVersion": "2.0", "Severity": 3, "Pid": 47, "Fields": {"msg": "Cache invalidation request failed.", "error": "TooManyInvalidationsInProgress('An error occurred (TooManyInvalidationsInProgress) when calling the CreateInvalidation operation: Processing your request will cause you to exceed the maximum number of in-progress wildcard invalidations.')", "traceback": "Uncaught exception:\n  File \"/usr/local/lib/python3.7/site-packages/kinto_signer/updater.py\", line 405, in invalidate_cloudfront_cache\n    'CallerReference': '{}-{}'.format(timestamp, uuid.uuid4())\n  File \"/usr/local/lib/python3.7/site-packages/botocore/client.py\", line 320, in _api_call\n    return self._make_api_call(operation_name, kwargs)\n  File \"/usr/local/lib/python3.7/site-packages/botocore/client.py\", line 623, in _make_api_call\n    raise error_class(parsed_response, operation_name)\n<class 'botocore.errorfactory.TooManyInvalidationsInProgress'>\nTooManyInvalidationsInProgress('An error occurred (TooManyInvalidationsInProgress) when calling the CreateInvalidation operation: Processing your request will cause you to exceed the maximum number of in-progress wildcard invalidations.')\n"}}
Dec 14 17:54:22 ip-172-31-10-135 docker-kinto[2604]: {"Timestamp":<PHONE_NUMBER>208252416, "Type": "kinto_signer.updater", "Logger": "kinto", "Hostname": "ip-172-31-10-135.us-west-2.compute.internal", "EnvVersion": "2.0", "Severity": 3, "Pid": 47, "Fields": {"msg": "Cache invalidation request failed.", "error": "TooManyInvalidationsInProgress('An error occurred (TooManyInvalidationsInProgress) when calling the CreateInvalidation operation: Processing your request will cause you to exceed the maximum number of in-progress wildcard invalidations.')", "traceback": "Uncaught exception:\n  File \"/usr/local/lib/python3.7/site-packages/kinto_signer/updater.py\", line 405, in invalidate_cloudfront_cache\n    'CallerReference': '{}-{}'.format(timestamp, uuid.uuid4())\n  File \"/usr/local/lib/python3.7/site-packages/botocore/client.py\", line 320, in _api_call\n    return self._make_api_call(operation_name, kwargs)\n  File \"/usr/local/lib/python3.7/site-packages/botocore/client.py\", line 623, in _make_api_call\n    raise error_class(parsed_response, operation_name)\n<class 'botocore.errorfactory.TooManyInvalidationsInProgress'>\nTooManyInvalidationsInProgress('An error occurred (TooManyInvalidationsInProgress) when calling the CreateInvalidation operation: Processing your request will cause you to exceed the maximum number of in-progress wildcard invalidations.')\n"}}
Dec 14 17:54:23 ip-172-31-10-135 docker-kinto[2604]: {"Timestamp":<PHONE_NUMBER>364969984, "Type": "kinto_signer.updater", "Logger": "kinto", "Hostname": "ip-172-31-10-135.us-west-2.compute.internal", "EnvVersion": "2.0", "Severity": 3, "Pid": 47, "Fields": {"msg": "Cache invalidation request failed.", "error": "TooManyInvalidationsInProgress('An error occurred (TooManyInvalidationsInProgress) when calling the CreateInvalidation operation: Processing your request will cause you to exceed the maximum number of in-progress wildcard invalidations.')", "traceback": "Uncaught exception:\n  File \"/usr/local/lib/python3.7/site-packages/kinto_signer/updater.py\", line 405, in invalidate_cloudfront_cache\n    'CallerReference': '{}-{}'.format(timestamp, uuid.uuid4())\n  File \"/usr/local/lib/python3.7/site-packages/botocore/client.py\", line 320, in _api_call\n    return self._make_api_call(operation_name, kwargs)\n  File \"/usr/local/lib/python3.7/site-packages/botocore/client.py\", line 623, in _make_api_call\n    raise error_class(parsed_response, operation_name)\n<class 'botocore.errorfactory.TooManyInvalidationsInProgress'>\nTooManyInvalidationsInProgress('An error occurred (TooManyInvalidationsInProgress) when calling the CreateInvalidation operation: Processing your request will cause you to exceed the maximum number of in-progress wildcard invalidations.')\n"}}
Dec 14 17:54:23 ip-172-31-10-135 docker-kinto[2604]: {"Timestamp":<PHONE_NUMBER>773406720, "Type": "kinto_signer.updater", "Logger": "kinto", "Hostname": "ip-172-31-10-135.us-west-2.compute.internal", "EnvVersion": "2.0", "Severity": 3, "Pid": 47, "Fields": {"msg": "Cache invalidation request failed.", "error": "TooManyInvalidationsInProgress('An error occurred (TooManyInvalidationsInProgress) when calling the CreateInvalidation operation: Processing your request will cause you to exceed the maximum number of in-progress wildcard invalidations.')", "traceback": "Uncaught exception:\n  File \"/usr/local/lib/python3.7/site-packages/kinto_signer/updater.py\", line 405, in invalidate_cloudfront_cache\n    'CallerReference': '{}-{}'.format(timestamp, uuid.uuid4())\n  File \"/usr/local/lib/python3.7/site-packages/botocore/client.py\", line 320, in _api_call\n    return self._make_api_call(operation_name, kwargs)\n  File \"/usr/local/lib/python3.7/site-packages/botocore/client.py\", line 623, in _make_api_call\n    raise error_class(parsed_response, operation_name)\n<class 'botocore.errorfactory.TooManyInvalidationsInProgress'>\nTooManyInvalidationsInProgress('An error occurred (TooManyInvalidationsInProgress) when calling the CreateInvalidation operation: Processing your request will cause you to exceed the maximum number of in-progress wildcard invalidations.')\n"}}
Dec 14 17:54:24 ip-172-31-10-135 docker-kinto[2604]: {"Timestamp":<PHONE_NUMBER>903221760, "Type": "kinto_signer.updater", "Logger": "kinto", "Hostname": "ip-172-31-10-135.us-west-2.compute.internal", "EnvVersion": "2.0", "Severity": 3, "Pid": 48, "Fields": {"msg": "Cache invalidation request failed.", "error": "TooManyInvalidationsInProgress('An error occurred (TooManyInvalidationsInProgress) when calling the CreateInvalidation operation: Processing your request will cause you to exceed the maximum number of in-progress wildcard invalidations.')", "traceback": "Uncaught exception:\n  File \"/usr/local/lib/python3.7/site-packages/kinto_signer/updater.py\", line 405, in invalidate_cloudfront_cache\n    'CallerReference': '{}-{}'.format(timestamp, uuid.uuid4())\n  File \"/usr/local/lib/python3.7/site-packages/botocore/client.py\", line 320, in _api_call\n    return self._make_api_call(operation_name, kwargs)\n  File \"/usr/local/lib/python3.7/site-packages/botocore/client.py\", line 623, in _make_api_call\n    raise error_class(parsed_response, operation_name)\n<class 'botocore.errorfactory.TooManyInvalidationsInProgress'>\nTooManyInvalidationsInProgress('An error occurred (TooManyInvalidationsInProgress) when calling the CreateInvalidation operation: Processing your request will cause you to exceed the maximum number of in-progress wildcard invalidations.')\n"}}
Dec 14 17:54:25 ip-172-31-10-135 docker-kinto[2604]: {"Timestamp":<PHONE_NUMBER>337822720, "Type": "kinto_signer.updater", "Logger": "kinto", "Hostname": "ip-172-31-10-135.us-west-2.compute.internal", "EnvVersion": "2.0", "Severity": 3, "Pid": 48, "Fields": {"msg": "Cache invalidation request failed.", "error": "TooManyInvalidationsInProgress('An error occurred (TooManyInvalidationsInProgress) when calling the CreateInvalidation operation: Processing your request will cause you to exceed the maximum number of in-progress wildcard invalidations.')", "traceback": "Uncaught exception:\n  File \"/usr/local/lib/python3.7/site-packages/kinto_signer/updater.py\", line 405, in invalidate_cloudfront_cache\n    'CallerReference': '{}-{}'.format(timestamp, uuid.uuid4())\n  File \"/usr/local/lib/python3.7/site-packages/botocore/client.py\", line 320, in _api_call\n    return self._make_api_call(operation_name, kwargs)\n  File \"/usr/local/lib/python3.7/site-packages/botocore/client.py\", line 623, in _make_api_call\n    raise error_class(parsed_response, operation_name)\n<class 'botocore.errorfactory.TooManyInvalidationsInProgress'>\nTooManyInvalidationsInProgress('An error occurred (TooManyInvalidationsInProgress) when calling the CreateInvalidation operation: Processing your request will cause you to exceed the maximum number of in-progress wildcard invalidations.')\n"}}
Dec 14 17:54:26 ip-172-31-10-135 docker-kinto[2604]: {"Timestamp":<PHONE_NUMBER>521855744, "Type": "kinto_signer.updater", "Logger": "kinto", "Hostname": "ip-172-31-10-135.us-west-2.compute.internal", "EnvVersion": "2.0", "Severity": 3, "Pid": 48, "Fields": {"msg": "Cache invalidation request failed.", "error": "TooManyInvalidationsInProgress('An error occurred (TooManyInvalidationsInProgress) when calling the CreateInvalidation operation: Processing your request will cause you to exceed the maximum number of in-progress wildcard invalidations.')", "traceback": "Uncaught exception:\n  File \"/usr/local/lib/python3.7/site-packages/kinto_signer/updater.py\", line 405, in invalidate_cloudfront_cache\n    'CallerReference': '{}-{}'.format(timestamp, uuid.uuid4())\n  File \"/usr/local/lib/python3.7/site-packages/botocore/client.py\", line 320, in _api_call\n    return self._make_api_call(operation_name, kwargs)\n  File \"/usr/local/lib/python3.7/site-packages/botocore/client.py\", line 623, in _make_api_call\n    raise error_class(parsed_response, operation_name)\n<class 'botocore.errorfactory.TooManyInvalidationsInProgress'>\nTooManyInvalidationsInProgress('An error occurred (TooManyInvalidationsInProgress) when calling the CreateInvalidation operation: Processing your request will cause you to exceed the maximum number of in-progress wildcard invalidations.')\n"}}
Dec 14 17:54:26 ip-172-31-10-135 docker-kinto[2604]: {"Timestamp":<PHONE_NUMBER>923068928, "Type": "kinto_signer.updater", "Logger": "kinto", "Hostname": "ip-172-31-10-135.us-west-2.compute.internal", "EnvVersion": "2.0", "Severity": 3, "Pid": 48, "Fields": {"msg": "Cache invalidation request failed.", "error": "TooManyInvalidationsInProgress('An error occurred (TooManyInvalidationsInProgress) when calling the CreateInvalidation operation: Processing your request will cause you to exceed the maximum number of in-progress wildcard invalidations.')", "traceback": "Uncaught exception:\n  File \"/usr/local/lib/python3.7/site-packages/kinto_signer/updater.py\", line 405, in invalidate_cloudfront_cache\n    'CallerReference': '{}-{}'.format(timestamp, uuid.uuid4())\n  File \"/usr/local/lib/python3.7/site-packages/botocore/client.py\", line 320, in _api_call\n    return self._make_api_call(operation_name, kwargs)\n  File \"/usr/local/lib/python3.7/site-packages/botocore/client.py\", line 623, in _make_api_call\n    raise error_class(parsed_response, operation_name)\n<class 'botocore.errorfactory.TooManyInvalidationsInProgress'>\nTooManyInvalidationsInProgress('An error occurred (TooManyInvalidationsInProgress) when calling the CreateInvalidation operation: Processing your request will cause you to exceed the maximum number of in-progress wildcard invalidations.')\n"}}
Dec 14 17:54:29 ip-172-31-10-135 docker-kinto[2604]: {"Timestamp":<PHONE_NUMBER>829135616, "Type": "kinto_signer.updater", "Logger": "kinto", "Hostname": "ip-172-31-10-135.us-west-2.compute.internal", "EnvVersion": "2.0", "Severity": 3, "Pid": 44, "Fields": {"msg": "Cache invalidation request failed.", "error": "TooManyInvalidationsInProgress('An error occurred (TooManyInvalidationsInProgress) when calling the CreateInvalidation operation: Processing your request will cause you to exceed the maximum number of in-progress wildcard invalidations.')", "traceback": "Uncaught exception:\n  File \"/usr/local/lib/python3.7/site-packages/kinto_signer/updater.py\", line 405, in invalidate_cloudfront_cache\n    'CallerReference': '{}-{}'.format(timestamp, uuid.uuid4())\n  File \"/usr/local/lib/python3.7/site-packages/botocore/client.py\", line 320, in _api_call\n    return self._make_api_call(operation_name, kwargs)\n  File \"/usr/local/lib/python3.7/site-packages/botocore/client.py\", line 623, in _make_api_call\n    raise error_class(parsed_response, operation_name)\n<class 'botocore.errorfactory.TooManyInvalidationsInProgress'>\nTooManyInvalidationsInProgress('An error occurred (TooManyInvalidationsInProgress) when calling the CreateInvalidation operation: Processing your request will cause you to exceed the maximum number of in-progress wildcard invalidations.')\n"}}
Dec 14 17:54:30 ip-172-31-10-135 docker-kinto[2604]: {"Timestamp":<PHONE_NUMBER>312627456, "Type": "kinto_signer.updater", "Logger": "kinto", "Hostname": "ip-172-31-10-135.us-west-2.compute.internal", "EnvVersion": "2.0", "Severity": 3, "Pid": 44, "Fields": {"msg": "Cache invalidation request failed.", "error": "TooManyInvalidationsInProgress('An error occurred (TooManyInvalidationsInProgress) when calling the CreateInvalidation operation: Processing your request will cause you to exceed the maximum number of in-progress wildcard invalidations.')", "traceback": "Uncaught exception:\n  File \"/usr/local/lib/python3.7/site-packages/kinto_signer/updater.py\", line 405, in invalidate_cloudfront_cache\n    'CallerReference': '{}-{}'.format(timestamp, uuid.uuid4())\n  File \"/usr/local/lib/python3.7/site-packages/botocore/client.py\", line 320, in _api_call\n    return self._make_api_call(operation_name, kwargs)\n  File \"/usr/local/lib/python3.7/site-packages/botocore/client.py\", line 623, in _make_api_call\n    raise error_class(parsed_response, operation_name)\n<class 'botocore.errorfactory.TooManyInvalidationsInProgress'>\nTooManyInvalidationsInProgress('An error occurred (TooManyInvalidationsInProgress) when calling the CreateInvalidation operation: Processing your request will cause you to exceed the maximum number of in-progress wildcard invalidations.')\n"}}

We shouldn't rely on cache invalidation anymore, so error during invalidation should not be a problem.
I think I spotted a place where we don't do cache busting, I'll look at it.


Aliases in imports

If I have node v16.13.1 and eslint 8.4.1, should eslint (without "settings" in eslintrc file) use node resolving for aliases configured with package.json?
package.json:
...
"imports": {
"#common/*": "./src/common/*.js"
},
...

This plugin uses resolve, which doesn't yet support "exports", or native ESM resolution, and thus, also doesn't support "imports" resolution.
As soon as resolve supports these things, this plugin will.

This plugin uses resolve, which doesn't yet support "exports", or native ESM resolution, and thus, also doesn't support "imports" resolution.
As soon as resolve supports these things, this plugin will.


Add some OS X support logic to Makefile

These are some hacks that should get VG building on Mac, without affecting the Linux build.
This is pull request 3 of 3 to get VG building on the Mac.
IMPORTANT:  You need to update VG's vcflib submodule to point to the latest vcflib (that merges my 2nd pull request).   And you need to update that vcflib to point to the latest tabixpp submodule (that merges my 1st pull request).   I am unable to change the submodule linking myself via pull request, without swapping in my own forks for these, which would probably be best to avoid.
Thanks!

Thanks for this!
Just a reminder that the Mac build won't work unless
vcflib https://github.com/ekg/vcflib/pull/97
vcflib/tabixpp https://github.com/ekg/tabixpp/pull/7
get merged too (and submodules updated in vg/)....
On Thu, Aug 6, 2015 at 4:39 AM, Erik Garrison<EMAIL_ADDRESS>wrote:

Merged #63 https://github.com/ekg/vg/pull/63.
—
Reply to this email directly or view it on GitHub
https://github.com/ekg/vg/pull/63#event-375066520.

Thanks! Now I need to update the submodules.
On Fri, Aug 7, 2015 at 1:56 PM, Glenn Hickey<EMAIL_ADDRESS>wrote:

Thanks for this!
Just a reminder that the Mac build won't work unless
vcflib https://github.com/ekg/vcflib/pull/97
vcflib/tabixpp https://github.com/ekg/tabixpp/pull/7
get merged too (and submodules updated in vg/)....
On Thu, Aug 6, 2015 at 4:39 AM, Erik Garrison<EMAIL_ADDRESS>wrote:

Merged #63 https://github.com/ekg/vg/pull/63.
—
Reply to this email directly or view it on GitHub
https://github.com/ekg/vg/pull/63#event-375066520.

—
Reply to this email directly or view it on GitHub
https://github.com/ekg/vg/pull/63#issuecomment-128682638.

@glennhickey, Would you please verify that the updated master now works for you?

OK, I just re-cloned and built from scratch successfully on my Mac.
Thanks!
On Fri, Aug 7, 2015 at 8:42 AM, Erik Garrison<EMAIL_ADDRESS>wrote:

@glennhickey https://github.com/glennhickey, Would you please verify
that the updated master now works for you?
—
Reply to this email directly or view it on GitHub
https://github.com/ekg/vg/pull/63#issuecomment-128690725.