Include ctx.key in ctx.console.* output

Currently the output from ctx.console.log and similar includes the service name, the invocation ID, and the timestamp. It would be very useful IMO if it included ctx.key for objects and workflows as well so we don't have to manually include it in every call. Any thoughts on this?

Thanks for the suggestion @dimfeld. I think this is a good idea for improving Restate's logging capabilities :-) @slinkydeveloper is the required information already present so that we can add it to log statements?

Looks like input.key can be passed into LoggerContext here to facilitate this:
https://github.com/restatedev/sdk-typescript/blob/443630750266be4402215263a971ef8eed313f3c/packages/restate-sdk/src/endpoint/handlers/generic.ts#L279-L285
since it's in ContextImpl which is created a few lines down https://github.com/restatedev/sdk-typescript/blob/443630750266be4402215263a971ef8eed313f3c/packages/restate-sdk/src/endpoint/handlers/generic.ts#L301-L304
I did notice that the ContextImpl class uses an accessor for key though, so it may be wise to reuse some of that code albeit without throwing an error when key doesn't apply.
https://github.com/restatedev/sdk-typescript/blob/443630750266be4402215263a971ef8eed313f3c/packages/restate-sdk/src/context_impl.ts#L122-L132

Piggy-backing off this issue - it would be nice in general to have access to the workflow/virtual object's state from the logger as well as it's key.

I added it in #455. this is the sample output:
[restate] [2024-10-30T14:30:32.185Z] INFO:  Listening on 9080...
[restate] [2024-10-30T14:30:32.187Z] WARN:  Accepting requests without validating request signatures; handler access must be restricted
[restate] [counter/my-todo/current][inv_1d5kQ1mT8mq25dhBiJt196gS7bmQw0oMsV][2024-10-30T14:30:33.289Z] INFO:  my log line


Update/02122021 scraping

This should bring everything up to date with the latest LinkedIn UI.
Fair warning, I encountered a new bug which has duplicate entries appearing in the logger feed which I have not yet identified the root cause of. Should target dev for now.
Please test the code prior to merging.

Merge conflicts should be resolved. Most of what was in dev was overwritten as it was way out of date anyway

Closed by PR!3


ocis dumpconfig

It would be nice to have a ocis command the would outomatically dump the used runtime config to the terminal as a yaml tree.
Fields containing confidential values should be automatically redacted (those could be marked using a custom tag at the variables definition in the code).
example:
$> ocis dumpconfig

Result:
token_manager:
  jwt_secret: <redacted>
machine_auth_api_key: <redacted>
transfer_secret: <redacted>
graph:
  spaces:
    insecure: true
  identity:
    ldap:
      bind_password: <redacted>
idp:
  ldap:
    bind_password: <redacted>
idm:
  service_user_passwords:
    admin_password: <redacted>
    idm_password: <redacted>
    reva_password: <redacted>
    idp_password: <redacted>
proxy:
  insecure_backends: true
frontend:
  archiver:
    insecure: true
  app_provider:
    insecure: true
auth_basic:
  auth_providers:
    ldap:
      bind_password: <redacted>
auth_bearer:
  auth_providers:
    oidc:
      insecure: true
user:
  drivers:
    ldap:
      bind_password: <redacted>
group:
  drivers:
    ldap:
      bind_password: <redacted>
storage_metadata:
  data_provider_insecure: true
storage_users:
  data_provider_insecure: true
ocdav:
  insecure: true
thumbnails:
  thumbnail:
    webdav_allow_insecure: true
    cs3_allow_insecure: true

Also see: https://github.com/owncloud/ocis/issues/3456 (Command line option to list active config parameters)

Duplicate of #3456, closing.


Update MIME type for woff

Hi,
I am getting this issue
Resource interpreted as Font but transferred with MIME type application/x-woff: "https://netdna.bootstrapcdn.com/font-awesome/3.0.2/font/fontawesome-webfont.woff?v=3.0.2"
I am getting Content-Type →application/x-woff
Please resolve for 3.0.2 version.
Issue Created at FortAwesome/Font-Awesome : FortAwesome/Font-Awesome
https://github.com/FortAwesome/Font-Awesome/issues/5372

Based on this: http://stackoverflow.com/questions/3594823/mime-type-for-woff-fonts
I will change it to application/font-woff, unless there are any objections?

Actually @jimaek, this is right in bootstrapcdn.com's Nginx mime.types file. This has to be an origin issue.
See: https://github.com/MaxCDN/bootstrap-cdn/blob/develop/mime.types#L84
Also, I verified on the origin that the correct nginx.conf and mime.types files are being used.
[XXXXX@XXXXX ~]$ ps aux | grep nginx.conf
502       2395  0.0  0.0   6372   664 pts/0    S+   19:04   0:00 grep nginx.conf
root     28174  0.0  0.1  56952  2404 ?        Ss    2014   0:00 nginx: master process /usr/local/nginx/sbin/nginx -c /home/XXXXX/bootstrap-cdn/nginx.conf
[XXXXX@XXXXX ~]$ cat bootstrap-cdn/nginx.conf |  grep mime.types
    include       /home/XXXXX/bootstrap-cdn/mime.types;
[XXXXX@XXXXX ~]$ cat bootstrap-cdn/mime.types  | grep woff
    application/font-woff         woff;

Curl's
bash-3.2$ curl -si "https://netdna.bootstrapcdn.com/font-awesome/3.0.2/font/fontawesome-webfont.woff?v=3.0.2" | head -n15 | grep Content-Type
Content-Type: application/x-woff
bash-3.2$ curl -si "https://maxcdn.bootstrapcdn.com/font-awesome/3.0.2/font/fontawesome-webfont.woff?v=3.0.2" | head -n15 | grep Content-Type
Content-Type: application/x-woff

@jmervine I have no access to Bootstrap's Origin unfortunately.

@jmervine: why don't you try implementing html5 boilerplate's nginx conf as per #362? It should fix most if not all the server issues.

@XhmikosR The version of nginx being run is a streamlined custom compile and nginx is configured to match. As @jimaek mentioned, it's not an Nginx issue. Admittedly I haven't combed through the html5 boilerplate, but as far as Nginx is concerned, I tend to prefer to roll my own, both binaries and configuration.

Suit yourself, but that it's a well tested boilerplate.

I've started going though the many "woff" fonts across the board, updating them to use "application/font-woff", but then noticed that S3's default mime type for .woff is "application/octet-stream". Which means, "woff" is an unrecognized extension per http://docs.aws.amazon.com/AWSImportExport/latest/DG/FileExtensiontoMimeTypes.html.
As such, I'm going to work with the MaxCDN guys and recommend moving off s3 as our origin, in the mean time, I've updated the above path and a few others (although the cache still needs to be purged at the time of writing this), but I'm going to hold off on the rest.

Haven't seen any reports of this issue in a while, pretty sure I got them all.


fix uml and remove hard-coded styles

Hi,
I'm using mermaid for a new site that I'm making that will be highly focused on software design.  However, there were two features that didn't work as I expected, so I changed them.  I'm submitting a PR here in case you want the changes too.

Firstly, there was hard-coded CSS setting the font to whatever was auto-detected in the browser.  This is fairly fragile.  I don't know why it was added, but it's probably an edge case or a "compatibility" thing.  I don't think anyone would expect this sort of feature, and it was surprising.

It was also causing problems when the font loads slowly on the page, randomly.  It also failed if I did anything different with font-size.  I really recommend leaving the users alone with their choice of font.  😁

The classes were mixed up or missing from the UML diagrams.  I fixed this, and now everything looks great.

Also: I noticed that some of the features being tested in the UML diagrams don't actually do anything, but they're also not failing.  I'm guessing they were features that aren't finished yet?   Can I help?

Pull Request Test Coverage Report for Build 689

1 of 1 (100.0%)  changed or added relevant line in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.05%) to 54.334%

Totals

Change from base Build 671:
0.05%

Covered Lines:
2053

Relevant Lines:
3754

💛  - Coveralls

Firstly, there was hard-coded CSS setting the font to whatever was auto-detected in the browser.

This is for portability. After the graph is generated, people might copy and use it somewhere else.  Inline the CSS could make it look the same everywhere. I know it has issues, but I don't have solution, unfortunately.

Also: I noticed that some of the features being tested in the UML diagrams don't actually do anything, but they're also not failing. I'm guessing they were features that aren't finished yet? Can I help?

Class diagram is experimental feature which is not finished. The original author has stopped working on this project. You are welcome to contribute.

Class diagram is experimental feature which is not finished. The original author has stopped working on this project. You are welcome to contribute.

I did a PR for this issue in here  #795


Not working on windows ( no readline ) but pyreadline is avalilable

Can You make it work with pyreadline ? Its the only one for windows, but when i simply change readline to pyreadline in dream.py then i get atribute errror , pyreadline has not attribute ' read_history_file'
Any way to get it working on win ??

Oh, so sorry.  If it doesn't work I'll simply disable readline functionality (which gives you command-line editing, etc) on systems that don't support GNU readline.
In the meantime, you could just delete all the lines of code that call readline functions and it should "just work" (tm)

I did it , removed history but now im getting error no module names ldm.simplet2i , and it wont run

Make sure that you are running python from the stable-diffusion directory. scripts and ldm should be subdirectories. Also check that the file ldm/simple2ti.py is present.
I just made a branch in which readline is disabled on machines that don't support it. Try checking out the branch named "noreadline-on-windows" and see if it behaves for you.

The file is present, i tried new branch and the issue is still the same, errors out with ldm.simplet2i , this file is not in main repo of original branch , maybe its a windows thing that its not working, maybe youd have to load the py file somehow first

Yes, that's a module I added to the upstream distribution. It is getting loaded in dream.py's main() function, which is an unusual place for it, but I did it so that the help message would print out quickly. Could you try applying the enclosed patch to dream.py? All it does it to move two import statements from main() up to the top where these are usually located.
I'm so sorry for the trouble! I don't have access to a Windows machine with a GPU, so this is all a bit of trial and error.

In case you can't gunzip and apply this patch, here it is in full. Just manually delete the two lines starting with "-" and add the two lines starting with "+" (without the - and + symbols)
--- scripts/dream.py 2022-08-18 15:59:31.607413000 -0400
+++ scripts/dream-test.py 2022-08-18 18:09:01.525402000 -0400
@@ -3,6 +3,8 @@
import shlex
import atexit
import os
+from pytorch_lightning import logging
+from ldm.simplet2i import T2I

 # readline will be disabled on windows systems
 try:
@@ -35,8 +37,6 @@
         setup_readline()

     print("* Initializing, be patient...\n")
-    from pytorch_lightning import logging
-    from ldm.simplet2i import T2I

     # creating a simple text2image object with a handful of
     # defaults passed on the command line.

The thing is i do it in notepad ++ i don have the tools to apply it as a patch

Ok. I suspect it has something to do with casing on Windows. I'll have to rename the module. It won't take long, but I need to help my wife out with packing for a trip, so look for something later this evening.

Do You know any other quick way to just load mode l once and keep prompting like on discord ?

Oh, just a thought. Have you tried running the txt2img.py script that's part of the original distrib? If it loads its modules OK, then it's definitely a problem with my code.

yeh the original works without any issues, and img2img works as well so main branch code from original repo is fine over here

I'm going to convince my son to let me install python on his gaming Windows computer so I can test it out for myself. But this is an absolutely solvable problem. If you would, could you cut and paste the error messages you get when you run dream.py?
Thx.
Also, in the longer term, I'm sure there will be plenty of web and GUI-based Windows packages for you to run locally. I did this just 'cause I can't wait and enjoy a bit of hacking on the side.

(ldm) D:\stabot\scripts>python dream.py
Traceback (most recent call last):
File "dream.py", line 7, in
from ldm.simplet2i import T2I
ModuleNotFoundError: No module named 'ldm.simplet2i'

Sure. Tell me how you want the files named and I can do that.
I'm working on my son's windows machine now and installing all the dependencies. Hopefully will reproduce your problem so I can fix.

Great,  the names of the prompt and seed at the end, pretty much like on discord would work the best i think to go back and modify the image later keeping same seed

Just finished install. I ran into a problem superficially similar to yours with the module not being found, but the easy solution was to replace "python3" with "python"
python3 scripts\dream.py  -- did not work
python  scripts\dream.py -- did work

But I doubt this is your problem because the original scripts are working fine for you. I'm using the Anaconda Powershell Prompt (miniconda3). Is this the same shell you're working with?

yes im on miniconda3 and i did used python , so your code works fine on windows over there ?

Conda is supposed to take care of path issues, and if the path was an issue then it wouldn't be able to find ldm.util, which is in the same directory as ldm.simplet2i. Maybe there's something wonky in your directory structure? Do me a favor and cut-and-paste the output of "dir ldm":

(ldm) PS C:\Users\linco\Projects\SD\stable-diffusion> dir ldm

    Directory: C:\Users\linco\Projects\SD\stable-diffusion\ldm

Mode                 LastWriteTime         Length Name
----                 -------------         ------ ----
d-----        2022-08-18   8:19 PM                data
d-----        2022-08-18   8:19 PM                models
d-----        2022-08-18   8:19 PM                modules
-a----        2022-08-18   8:19 PM           3980 lr_scheduler.py
-a----        2022-08-18   8:19 PM          18097 simplet2i.py
-a----        2022-08-18   8:19 PM           6056 util.py

Windows decided to do updates and its pretty slow now, i did not change anything with the structure, unpacked repo to STABOT folder on D drive and moved model to correct folder , its at 100% so ill post contents asap

No worries. This is probably not going to be helpful, but I'm running out of ideas. I appreciate your patience.

(base) D:\stabot>dir ldm
Volume in drive D is Ai
Volume Serial Number is 0A27-FD6B
Directory of D:\stabot\ldm
18/08/2022  23:35              .
18/08/2022  23:35              ..
18/08/2022  23:35              data
18/08/2022  22:00             3,882 lr_scheduler.py
18/08/2022  23:35              models
19/08/2022  00:29              modules
18/08/2022  22:00            17,682 simplet2i.py
18/08/2022  22:00             5,855 util.py
3 File(s)         27,419 bytes
5 Dir(s)  43,136,602,112 bytes free

Can You tell what python you have installed ? maybe if ill repeat your installation then it will run

OK fixed it! i had to move allyour python scripts to main folder ...

Wow! I'm so happy you got it figured out. You know, this reminds me that I had the same problem when I first installed the original source code (modules couldn't be found in their subdirectories, but only in main folder). It turned out that the Conda environment was borked. In that case, deleting all Conda's files and rebuilding did the trick.
When you launch the script, pass the option "--sampler ddim" to get the DDIM sampler. Unfortunately the k_lms sampler that the discord bot uses is not part of the upstream package. Presumably they will add it at some point and then I'll merge.
I will fix the code so that the sampler does not terminate the program, but just issues a message and returns to the command prompt. Did you mean -S 57457 in your example? Lowercase -s is number of steps, which would be crazy high.
The next time the plms sampler gives you an error please send the stack trace. I'm going to close the issue now. Feel free to reopen. I moved your request to add seed and prompt to filenames to a different issue tracker (it is issue #2)

OK fixed it! i had to move allyour python scripts to main folder ...

What do you mean by this? can I get a more step by step on that

Maybe it would be possible to use prompt_toolkit as an alternative. It works on Linux and Windows and should have all the features of readline, but it is also designed for making full on text user interfaces so it might be a bit overkill. Only ~380KiB though


Bring the styling of the privacy policy in line with the other public-facing pages (it's UGLY)

Summary
Bring the styling of the privacy policy in line with the other public facing pages
Why?
It is really, really ugly and jarring.  Doesn't look like we know what we're doing.
Details
There's a certain amount of freedom here,  but use the landing page as your guide as to the flavour
Criteria for completion

[ ] A much prettier privacy policy (with all the info intact, of course)

I can take this!

Thank you!

We have an open PR that looks good, visual-wise, but needs some adjustments to bring it in line with our architectural direction.  So, still open.


Ignore/remove .DS_Store files

This is a very common issue when using git on a Mac, but to remove stray/irrelevant .DS_Store files from a git repo retroactively, you can do this:
Create a new file in the root directory of the repo called .gitignore with this content:
.DS_Store

Then, run the following commands to add and apply .gitignore retroactively:
git add .gitignore
git rm -r --cached .
git add .
git commit -a -m 'Ignore .DS_Store files retroactively.'

closed by https://github.com/ua-snap/epa-justice/commit/460778337e670c923211eb31e6a522982b9003fd


GIL issues with cfunc calling numpy code

I have an issue that I think is related to #1998. I'm creating cfuncs which I call from c++ code that releases the gil before it runs. Sometimes the cfuncs have code using numpy arrays, when that happens my program crashes.
Is there a way for me to:

Detect that a function to be compiled uses numpy or anything that might require the gil to be in a specific state? Specifically in my code I have custom type and I use overload_method to add a 'to_array' method to it. So, in my case I just need a way to be notified when calling numba.cfunc(..)(my_func) that a call to 'to_array' was used.
When I get the indication from 1. I would like to wrap the function in a context-manager-like acquire/release gil, similarly to how the parallel ufunc issue was solved here.

I actually find the reason for my crash and it was not really related to numpy trying to acquire the gil. Nevertheless I think I'm still exposed to the same possible deadlock as #1998 and would still welcome some solution that allows a numba user to better track when gil manipulation is required and a way to manipulate the gil.

It looks like cfunc is incorrectly releasing the GIL by default, even when the compiled code is not in nopython mode.

Is there any ETA on getting this issue fixed? Thanks.


[ISSUE #3179] resource add button gives an error

// Describe your PR here; eg. Fixes #issueNo

Make sure that:

[x] You have read the contribution guidelines.
[x] You submit test cases (unit or integration tests) that back your changes.
[x] Your local test passed mvn clean install -Dmaven.javadoc.skip=true.

Codecov Report

Merging #3181 (9082246) into master (9e163a6) will decrease coverage by 0.13%.
The diff coverage is n/a.

@@             Coverage Diff              @@
##             master    #3181      +/-   ##
============================================
- Coverage     57.52%   57.38%   -0.14%
+ Complexity     4532     4526       -6
============================================
  Files           730      730
  Lines         20818    20818
  Branches       1915     1915
============================================
- Hits          11976    11947      -29
- Misses         7792     7817      +25
- Partials       1050     1054       +4

Impacted Files
Coverage Δ

...he/shenyu/admin/controller/ResourceController.java
100.00% <ø> (ø)

...yu/sync/data/http/refresh/AbstractDataRefresh.java
70.00% <0.00%> (-13.34%)
:arrow_down:

...henyu/admin/service/impl/UpstreamCheckService.java
61.42% <0.00%> (-8.58%)
:arrow_down:

...che/shenyu/sync/data/http/HttpSyncDataService.java
77.23% <0.00%> (-6.51%)
:arrow_down:

...henyu/plugin/grpc/resolver/ShenyuNameResolver.java
58.51% <0.00%> (-5.32%)
:arrow_down:

Continue to review full report at Codecov.

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


linkableSchemaTypes is now a required option for setup.

As the title says, in version 1.3.0 linkableSchemaTypes is now required to setup this plugin. Not doing so results in errors.

Thanks for the heads-up! This is fixed in v1.3.1.


fix: exporting modules as default

Coverage remained the same at 86.73% when pulling 73efaf6a6830cd3a1bd3230fc835626d66b0a053 on export_modules into 3c5ddcbf7e5092eece8027b5da7f05a425a7cd76 on master.


[WIP] Un-Staticable

Refactoring & Add test cases.

Codecov Report

Merging #5 into master will increase coverage by 58.2%.
The diff coverage is 100%.

@@             Coverage Diff             @@
##             master      #5      +/-   ##
===========================================
+ Coverage         0%   58.2%   +58.2%
- Complexity        0      16      +16
===========================================
  Files             2       2
  Lines            67      67
  Branches          8       8
===========================================
+ Hits              0      39      +39
+ Misses           67      23      -44
- Partials          0       5       +5

Impacted Files
Coverage Δ
Complexity Δ

...m/github/kazy1991/dependencykit/DependencyKit.java
52% <100%> (+52%)
11 <0> (+11)
:arrow_up:

...java/com/github/kazy1991/dependencykit/Module.java
76.47% <0%> (+76.47%)
5% <0%> (+5%)
:arrow_up:

Continue to review full report at Codecov.

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

Codecov Report

Merging #5 into master will increase coverage by 58.2%.
The diff coverage is 100%.

@@             Coverage Diff             @@
##             master      #5      +/-   ##
===========================================
+ Coverage         0%   58.2%   +58.2%
- Complexity        0      16      +16
===========================================
  Files             2       2
  Lines            67      67
  Branches          8       8
===========================================
+ Hits              0      39      +39
+ Misses           67      23      -44
- Partials          0       5       +5

Impacted Files
Coverage Δ
Complexity Δ

...m/github/kazy1991/dependencykit/DependencyKit.java
52% <100%> (+52%)
11 <0> (+11)
:arrow_up:

...java/com/github/kazy1991/dependencykit/Module.java
76.47% <0%> (+76.47%)
5% <0%> (+5%)
:arrow_up:

Continue to review full report at Codecov.

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


Incompatibility with SUNDIALS 4.0.0

Sundials interface modified after Sundials release 4.0.0.  File arkode_spils.h, which is included in file sundials.cpp, do not exist anymore.

Hi @hillyuan,
You are right: currently MFEM only supports v2.7 and v3.x of SUNDIALS. We are working on switching to v4.0.

@gardner48, any progress on the sundials 4.0 support in mfem?

I've worked up two approaches for updating the sundials interfacing and will be sending around a description of the plan in the next day or two to see what sounds best to everyone.

Lets continue this discussion at #923


Calling a function that returns a function in wire.Build results in the unhelpful "unknown pattern" error

Describe the bug
Calling a function that returns a function in wire.Build results in the unknown pattern error.
To Reproduce
This may be in a shared package, to be used across multiple projects, for example.
func ProvideDDBClientWith(ddbEndpoint string) func(client.ConfigProvider) dynamodbiface.DynamoDBAPI {
	return func(awsSession client.ConfigProvider) dynamodbiface.DynamoDBAPI {
		return dynamodbclient.New(awsSession, ddbEndpoint)
	}
}

Elsewhere, that would be called in wire.Build like so:
func Inject(cfg Config) (Server, func(), error) (
    wire.Build(
        ...
        ProvideDDBClientWith(cfg.DDBEndpoint),
        ...
    )

    return Server{}, nil, nil
}

Expected behavior
Running wire would result in a properly generated Inject function.
Version
v0.4.0
Additional context
The package that has the Provide* function doesn't (and shouldn't) know where its arguments come from. It's up to the caller to load them from file, environment, or just hard code them. But that Provide* function will return a closure that's to be used by wire.Build.
For what it's worth, this works with fx.

This is closely related to #184. I'm not fully sure the implications of allowing the provider function to be dynamic.
For this case, you could use a slightly different provider function in your injector that instantiates the DynamoDB API:
func ProvideDDBClient(cfg Config, awsSession client.ConfigProvider) dynamodbiface.DynamoDBAPI {
	return dynamodbclient.New(awsSession, ddbEndpoint)
}

func Inject(cfg Config) (Server, func(), error) (
    wire.Build(
        // ...
        ProvideDDBClient,
        // ...
    )

    return Server{}, nil, nil
}

ddbEndpoint is not in scope in that ProvideDDBClient example. Additionally, my goal is for this function (ProvideDDBClient) to live in a shared package, while Config is specific to the consumer of that shared package.
I'm aware that something like this could be done (which maybe is what you meant?), but my goal is to reduce repeated code by putting it in shared packages.
func provideDDBClient(cfg Config, awsSession client.ConfigProvider) dynamodbiface.DynamoDBAPI {
	return dynamodbclient.New(awsSession, cfg.DDBEndpoint)
}

func Inject(cfg Config) (Server, func(), error) (
    wire.Build(
        // ...
        provideDDBClient,
        // ...
    )

    return Server{}, nil, nil
}

While I'm using a single provider function as an example, in reality I have many that I would like to make available in packages shared across a set of projects we're working on. It would significantly simplify my wire.Build setup for multiple projects.

This is still tagged as needs info. What's the additional info that's needed?

It'd be nice to see a solution for this. My use case is a provider that can be built with functional options. Something like this:
type Value struct {}
type ValueProvider func() (*Value, func(), error)
func ProviderWithOptions(options ...ProviderOption) ValueProvider {
    return func() (*Value, func(), error) {
        // ...
    }
}

I'd like to be able to use it inline in a wire.Build call like this:
ProviderWithOptions(WithOptionA(), WithOptionB())

My goal is to allow some customization of the provider, especially for things like migrations in a large codebase, or behavior that needs to be otherwise toggled or configured at build time. This isn't possible, currently. I need to wrap the customization in a provider function to appease wire:
func provider() (*Value, func(), error) {
    return ProviderWithOptions(WithOptionA())()
}

This gets especially cumbersome and boilerplatey when the provider has dependencies, as the type signature needs to be repeated in a number of places, and dependencies need to be manually passed in from the func to the invocation of the built provider function.
Regarding this concern:

I'm not fully sure the implications of allowing the provider function to be dynamic.

I feel like I can achieve a lot of potentially-scary dynamic behavior with the workaround, so it'd be nice to not have to write the workaround.


Support for Devise 4.x

I'm upgrading Devise to 4.x version in one of my Rails app and I was surprised that devise-async downgrade the version.
-    devise (3.5.10)
+    devise (4.1.1)
       bcrypt (~> 3.0)
       orm_adapter (~> 0.1)
-      railties (>= 3.2.6, < 5)
+      railties (>= 4.1.0, < 5.1)
       responders
-      thread_safe (~> 0.1)
       warden (~> 1.2.3)
-    devise-async (0.10.1)
-      devise (~> 3.2)
-    devise-token_authenticatable (0.4.6)
-      devise (>= 3.5.2, < 4.0.0)
+    devise-async (0.7.0)
+      devise (>= 2.2)
+    devise-token_authenticatable (0.5.0)
+      devise (>= 4.0.0, < 4.2.0)

I see a branch with some work related with Devise 4.x. I don't know if this branch needs too much work or it's ready to be merged. Let me know if I can help.

Hey @arturoherrero, in this branch I started with the work for the support of devise 4.x. As noted in the Changelog the current version of devise-async will only support devise 3.
As of now, there is one failing spec when using devise 4 and I did not have the time to deep dive into it. Feel free to have a look into it. Help is much appreciated!

I've done a quick test and it seems it's not calling to send_devise_notification .

Just a thought: Could this be drastically simplified by relying on ActiveJob?
https://github.com/plataformatec/devise#activejob-integration

This issue - the failing spec - was introduced by a change in devise (first bullet point). I looked into it and with the current test setup - the test running within a transaction - it is not possible to solve this problem as far as I can tell. Here are my thoughts:

send_devise_notification is not called as devise now uses an after_commit instead of after_create,
the test runs within a transaction which means that the confirmation email is not being sent as after_commit is not called within an open transaction,
even if you remove the test being wrapped within a transaction, changed? is false as the record has already been saved when after_commit gets triggered,
you could use previous_changes.any? which is available within after_commit, however, this leads to a lot of other tests failing.

I do not have the time to dive deeper and find a solution for this. If you need a similar means to send notifications delayed in devise 4+ I strongly advise to switch to ActiveJob for Rails 4.2+. If you need the functionality of this gem for using devise 4 in Rails < 4.2 you probably need to help me out on this.

@tmaier awesome.
This worked great, and with no need of an aditional gem.

Can anybody please share the patch?

I would like to test a possible patch, this issue is preventing the new gitlab from going in Debian and Ubuntu next releases

Any news when support for Devise 4 will be available?

gitlab is now devise-async free, so there is no hurry anymore

@giedriusr Please have a look at a past comment of mine: https://github.com/mhfs/devise-async/issues/94#issuecomment-225162455.

@baschtl thanks, will follow these suggestions.

@baschtl Will code changes & test cases under a303ee9 suffice OR we should consider few more scenario's/changed within it?

Howdy @baschtl, any news about support for Devise 4 in devise-async? Thanks.

Hey @Nowaker, I commented on https://github.com/mhfs/devise-async/pull/98 but haven't got any feedback. Feel free to have a look at it. I guess I have to make the changes myself at some point.

No need of this gem after following steps at: https://github.com/mhfs/devise-async/issues/94#issuecomment-225162455

Hey @baschtl and @giedriusr, thanks for your response. Here's my thoughts what could be done with this gem.

No need of this gem

As an ordinary Devise user, it makes more sense to me to simply depend on devise-async gem that gets the job done. The gem knows what method to override, what to do with each parameter, etc.
When I have my own def send_devise_notification(notification, *args) within models, I have to follow Devise implementation details to match my implementation with theirs.
Here's the solution I would suggest:

If you need a similar means to send notifications delayed in devise 4+ I strongly advise to switch to ActiveJob for Rails 4.2+ within devise-async and drop support for Rails <4.2

The gem would become almost a one-liner gem that does only this. This way, when a developer migrates to Rails 5, all they do is bump devise-async along the way.
We would release a new version, 0.10.3, which would only restrict Rails to < 5. And then another version 1.0.0 that requires Rails >= 5.
Your thoughts?

@Nowaker That sounds like a great idea! I will try to set something up.

Please try out https://github.com/mhfs/devise-async/releases/tag/v1.0.0beta of this gem and give me feedback on how it works in connection with devise 4.x.
This release implements the suggestion of @Nowaker. Which means you need to set up ActiveJob in your Rails app.

Closing this as the latest release depends on ActiveJob and implements the suggestion discussed in the last comments.


Missing option.txt in beta driver

https://github.com/itsmikethetech/Virtual-Display-Driver/releases/tag/23.12.2HDR does not contain the option.txt file inside the folder

in the beta, vdd_settings.xml have replaced  the options.txt, if you still want to base it on options.txt you can put your old options.txt into the folder and rename vdd_settings.xml. The driver will then look for options.txt and adapter.txt if adapter.txt isn't found it will go woth the gpu with most dedicated videoram. And in worst case scenario, it will ahve a few "sane" default resolutions.

it's best to have the "readme" updated to avoid confusion
I personally feel more confident with documentation that changes with release version, there are often stuff in betas that never makes it to the release.

it's best to have the "readme" updated to avoid confusion

I personally feel more confident with documentation that changes with release version, there are often stuff in betas that never makes it to the release.

Something that could be done instead is to document installation for betas, so there's better testing if users know how to install it!

That is true, it could be done. But since we are a small team and we all have life outside of VDD,  Function comes and bug fixes come before user-documentation. It's an open source project, with a discord server, where we gladly help someone interested in documenting or help develop the project. Time is just as limited to me as it is for you, and you have to prioritize. Anyway, if you are using a beta you are expected to know enough to figure things out, or at least know where to get a hold of the information you think is lacking.And since the beta is built to use options.txt if the provided vdd_settings.xml is missing. just the name vdd_settings.xml should give you a hint if your options.txt isn't used.

I have been commenting to any seeming related posts trying to get my solution out there. If you are annoyed with the XML files you can convert between xml or txt or just do it all in the GUI.
Virtual Display Driver: Wizard
A GUI tool for manipulation (Install / Uninstall / Reload / Configure) of Indirect Display Driver Sample (IddSample) implementations like the HDR capable Virtual Display Driver from itsmikethetech that works on Windows 10/11. This installer/configuration tool is intended to provide a more elegant solution in place of needing to edit configs or use Device Manger for driver installation.
https://github.com/sofmeright/VirtualDisplayDriver_Wizard/blob/main/README.md

it's best to have the "readme" updated to avoid confusion

I personally feel more confident with documentation that changes with release version, there are often stuff in betas that never makes it to the release.

Something that could be done instead is to document installation for betas, so there's better testing if users know how to install it!

Updated readme and relevant questions answered.


feat: new console sdk and typings

What does this PR do?
(Provide a description of what this PR does.)
Test Plan
(Write your test plan here. If you changed any code, please provide us with clear instructions on how you verified your changes work.)
Related PRs and Issues
(If this PR is related to any other PR or resolves any issue or related to any issue link all related PR and issues here.)
Have you read the Contributing Guidelines on issues?
(Write your answer here.)

Closing in favor of https://github.com/appwrite/console/pull/838


button text is focusable

hey i found that every button key  in calculator is not focusable
here you can see

i set this issue

Solved on #36


Specify version in pyproject.toml

Fixes https://github.com/MarshalX/python-libipld/issues/52

Thank you! Should we use
dynamic = ["version"]

instead?
I really do not want to specify the same version and many places

Yes, that also fixes the issue. PR amended. A new point release would be welcome, to fix the build in conda-forge: https://github.com/conda-forge/libipld-feedstock/pull/3


Linking errors on staging-next, missing flags

Issue description
The following issue can be seen on several builds:
https://nix-cache.s3.amazonaws.com/log/piwrmvacwqvzhqa4j2idmrxbz4xcrd6g-timemachine-0.3.1.drv
/nix/store/bxgwclk8kjjczlrkilwb12jhcm0n8syk-binutils-2.30/bin/ld: meters.o: undefined reference to symbol 'log10@@GLIBC_2.2.5'
/nix/store/p8fyjvz3djclmndwxjfcj7zkmx89wniw-glibc-2.27/lib/libm.so.6: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
make[2]: *** [Makefile:364: timemachine] Error 1
make[2]: Leaving directory '/build/source/src'
make[1]: *** [Makefile:368: all-recursive] Error 1
make[1]: Leaving directory '/build/source'
make: *** [Makefile:309: all] Error 2
builder for '/nix/store/piwrmvacwqvzhqa4j2idmrxbz4xcrd6g-timemachine-0.3.1.drv' failed with exit code 2

https://nix-cache.s3.amazonaws.com/log/i0h4pfb327cjc8dmp0ypbqzrvsw5ykip-lash-0.5.4.drv
/nix/store/bxgwclk8kjjczlrkilwb12jhcm0n8syk-binutils-2.30/bin/ld: lashd-alsa_mgr.o: undefined reference to symbol 'pthread_cancel@@GLIBC_2.2.5'
/nix/store/p8fyjvz3djclmndwxjfcj7zkmx89wniw-glibc-2.27/lib/libpthread.so.0: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
make[2]: *** [Makefile:340: lashd] Error 1
make[2]: Leaving directory '/build/lash-0.5.4/lashd'
make[1]: *** [Makefile:327: all-recursive] Error 1
make[1]: Leaving directory '/build/lash-0.5.4'
make: *** [Makefile:237: all] Error 2
builder for '/nix/store/i0h4pfb327cjc8dmp0ypbqzrvsw5ykip-lash-0.5.4.drv' failed with exit code 2

https://nix-cache.s3.amazonaws.com/log/agp0brdp9s78w8j1zxpg0xwqwrayg4gw-tangogps-0.99.2.drv
/nix/store/bxgwclk8kjjczlrkilwb12jhcm0n8syk-binutils-2.30/bin/ld: callbacks.o: undefined reference to symbol 'acos@@GLIBC_2.2.5'
/nix/store/p8fyjvz3djclmndwxjfcj7zkmx89wniw-glibc-2.27/lib/libm.so.6: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
make[2]: *** [Makefile:353: tangogps] Error 1
make[2]: Leaving directory '/build/tangogps-0.99.2/src'
make[1]: *** [Makefile:376: all-recursive] Error 1
make[1]: Leaving directory '/build/tangogps-0.99.2'
make: *** [Makefile:285: all] Error 2
builder for '/nix/store/agp0brdp9s78w8j1zxpg0xwqwrayg4gw-tangogps-0.99.2.drv' failed with exit code 2

Technical details
Please run nix-shell -p nix-info --run "nix-info -m" and paste the
results.

These errors say which library was missing on the command line, e.g. that tangogps is missing -lm.

It surprised me to see several occurrences of this. It made me wonder whether there have been any underlying changes.

I find it very likely to have been triggered by #51770.  I have a local rebuild in progress verifying that (local revert of that change atop staging-next).

Gentoo is patching them to add the missing libraries:
https://data.gpo.zugaina.org/gentoo/media-sound/timemachine/timemachine-0.3.3-r1.ebuild
https://data.gpo.zugaina.org/gentoo/media-sound/timemachine/files/timemachine-0.3.3-underlinking.patch

Confirmed that was the commit.  I haven't looked deeply into this PR/issue, but I expect it will be best to patch the individual expressions, e.g. simply extend LDFLAGS for those derivations.  I wonder why the error (apparently) doesn't happen on some distributions and does on others.

I believe there are approximately 50 expressions that would need patching for x86_64-linux platform based on the latest staging-next evaluation accounting for direct failures from this change.

I've been collecting some fixes on https://github.com/NixOS/nixpkgs/compare/staging-next...pbogdan:dt-needed (mostly just adding LDFLAGS as needed, mixed with some patches). As far as differences between Nix(OS) and other distros so far I've seen examples of:

other distros already patching the issue
differences in flags propagated from within transitive dependencies via pkg-config
differences in behaviour of the build system
differences in configure flags skipping build of some parts of the code

though I haven't inspected each and every failing package beyond adding needed flags (or adding patches where I did).


Update OneSignal Android to 3.10.8

Just updating to the latest native Android SDK to fix a few bugs that have been affecting my app and I'm sure are affecting others. https://github.com/OneSignal/OneSignal-Android-SDK/releases/tag/3.10.8

@rawrmaan Thanks for the PR, looks good as no major changes were made in the Android native SDK.


GEODE-8382: Run Redis tests against Redis API for Geode

We would like to run Redis's tests against Redis API for Geode.  Tests will run a separate job in the PR and main pipelines.  It has been included in the 'tests' jinja variables.
Co-authored-by: Murtuza Boxwala<EMAIL_ADDRESS>

Tested new pipeline job here: https://concourse.gemfire-ci.info/teams/developer/pipelines/sabbeypivotal-pipelining-pr

The pipeline linked is not publicly viewable, so it is harder to assert that it is indeed working

The pipeline linked is not publicly viewable, so it is harder to assert that it is indeed working

Good point, Mike.  The pipeline was tested locally, feel free to deploy a local version to make sure it works.
DUnit failure is unrelated to this change.

@smgoller @rhoughton-pivot @onichols-pivotal @dickcav


Persistent post database.

A possible solution to issues like the localtime vs. UTC thing might be to keep a database of all images that have been downloaded. I'm thinking that the user and the file's basename (as on the IG servers) can be used. (Assuming the filenames are at least locally unique with regards to their owner.) If each file was stored as user/22382_5984....jpg and hard-linked to whatever filename-pattern for the post is. Then the file would not have to be re-downloaded if filename-pattern is changed by the user, or Instaloader changes its behaviour (or even if the pattern differs because the post is requested by its hashtag, if it was previously downloaded from feed or profile).
With a logic similar to:
def download(url, user, dest): # dest based on pattern
        raw_name = os.path.join(db_root, user, os.path.basename(url))
        if os.path.isfile(dest):
                if not os.path.isfile(raw_name):
                        os.link(dest, raw_name)
                return False
        if os.path.isfile(raw_name):
                if not os.path.isfile(dest):
                        os.link(raw_name, dest)
                return False
        actually_download(url, dest)
        os.link(dst, raw_name)
        return True

User's numeric ID could be used to really make it persistent, without having to rename if the username changes. But I don't know if non-unix systems have something like hard-links, IIRC Windows introduced something akin to symlinks around Vista.
Symbolic links could also be used, but in either case there would be an issue of redundant files if either the "raw" or "pattern" file was removed. Residual files taking up space and dangling symlinks, for hard and symbolic links, respectively. (Which could easily be solved by find download_dir -name '*.jpg' -links 1 -delete or find -L download_dir -type l -delete. But that might be an excessive burden on the user.) Another way could be to just store the information in a user-id.json file containing a Dict[str, List[str]] of { "raw-name.jpg" : ["stored-as-pattern-A.jpg", "stored-as-pattern-B.jpg"] }, where the files might as well be hard-linked, but only to one-another, and no raw-name.jpg would appear on the file system.
Any thoughts?

I guess you have all figured out by now, but why can't you save timestamp from last successful run (or update)? You don't have to store all images (or hashes/links) to --fast-update work, right?
You can compare the last run timestamp with current timestamp and download required missing data (photos/videos/stories and whatever). If so, database would keep track of scraped users id and timestamp only. If i am not wrong, you can also extract id from a post. I don't know if it works for stories too.
In the last commit https://github.com/instaloader/instaloader/commit/903d882015f30148b6a1e3d5c6aea470f039ae56 seems like you download data, calculate hash and then checks if its on database. That might have some impact on Instagram limits.

I'm inclined to agree with @raphaelbernardino - the main point is to avoid having to re-download old images with a new pattern.

seems like you download data, calculate hash and then checks if its on database. That might have some impact on Instagram limits.

By reading 903d882 I don't think there would be a difference in the number of requests with a timestamp database. Both approaches would request a set of data (shortcode, timestamp, url etc.) for some posts. The current code checks the hash of the old file on the filesystem, and (if it matches what was stored when it was downloaded) links it to the new filename.
As far as I understand there is no limit on the number of images downloaded, just GQL-queries. It still saves some bandwidth and storage space to not have to re-download a #cutecat post that already occured in my :feed by just hardlinking them together. But it would probably be much easier (and non-unix compatible) to implement a db-table consisting only of target and utc-timestamp. And accept the extra bandwidth cost. Another plus for the timestamp db is that I could delete old images from my filesystem, if they aren't needed for --fast-update.
There are also some issues with the current approach, storing os.path.abspath(file) will make the db useless if I move the entire tree. And if I've just downloaded a profile I'm following, some recent post might make --fast-update :feed stop prematurely.  The db also violates 1NF, a pet-peeve of mine. :)
If one just wants to rename old files according to a new pattern, an external script could be used to parse the stored json files.
tl;dr: A timestamp database solves the main issue (relying on file existance from an old pattern), works on windows and would probably be overall simpler.

If one just wants to rename old files according to a new pattern, an external script could be used to parse the stored json files.

I drafted an external script to parse the stored json files and mass rename according to a new pattern:
https://gist.github.com/aandergr/69e08367d6b9632375691dda35eb649c


Dutch _National _Flag Algorithm

It is a special type of sorting algorithm that can sort in just O(n) and it is widely asked in interviews. Thus it will be a great addition to the sorting algorithms part.
@anubhavitis  Please do assign me this. I am a GSSOC participant and would love to contribute here.

Hi @anubhavitis , I am GSSoC'21 participant and I want to do it in C++. Please assign me this.

@machine-sg  i am already working on this one.Please do find some other issue to work on.

Hey, I’m a GSSOC'21 participant.I'd like to provide an understandable code with proper comments for this issue in Java.
Please assign this issue to me.


add cdsapi to access-med?

This is a suggestion - maybe we do not need this if it is only us who download this data from CDS (https://cds.climate.copernicus.eu/) onto Gadi. I have installed a version in my home directory.
cdsapiclient enables python-based automated download from Climate Data Storage.
For installation, see:
https://cds.climate.copernicus.eu/api-how-to#use-the-cds-api-client-for-data-access

I think we need to define what we want the conda med environment to be. I don't want it to be cluttered with too many things... Lets put this one on hold...


Error "Updating huesyncbox media_player took longer than the scheduled update interval 0:00:02"

Describe the bug
Somtimes when I use my automation (if hue syncbox is idle and tv is on then do hue syncbox sync_on) it does trigger but does not start the sync. In my log i have this
Logger: homeassistant.components.media_player
Source: helpers/entity_platform.py:692
Integration: Mediaplayer (documentation, issues)
First occurred: 16. September 2021, 06:51:50 (167 occurrences)
Last logged: 16:24:47

Updating huesyncbox media_player took longer than the scheduled update interval 0:00:02

Expected behavior
Send a sucessfull sync_on to the box
Environment
Official docker image

Home Assistant Core version: 2021.9.7
Home Assistant operating environment (OS/Container/Supervised/Core): Docker
Huesyncbox integration version: 1.14.0

The Updating huesyncbox media_player took longer than the scheduled update interval 0:00:02 lines are kind of expected to happen occasionally. Typically the box returns an answer really fast (couple of milliseconds), but sometimes it seems busy and can take a bit longer. I get a couple of these a day on my setup.
I could make the poll interval longer again (it was lowered from 10 to 2 in the last update), but it would take longer for the integration to get in sync with the status of the box, which is a problem when building automations around it.
Seeing that line would only mean that the status of the integration will lag behind with ~2 seconds. So as long is it is not occurring around the time that the status of the box changes and your automation triggers it should not be an issue.
That being said, could you post your automation (the yaml) so I can try to reproduce it.
I would expect request errors to the box to be logged by HA since it is an Exception, but maybe that is not (always?) the case, I would need to examine that in more detail.
It would really help if you could enable the aiohuesyncbox logging by adding or extending the section below in your configuration.yaml. And save it when the issue occurs. However it is really spammy as it logs each request to the box (which means every 2 seconds) and it prints quite a lot of data. But it is the only way to really see what is going on on the communication level.
logger:
  default: info
  logs:
    aiohuesyncbox: debug

Hi, thanks for your answer. I can do that, when I am back home. But I think the poll is correct every time. The automation triggers but the part which is not running is the action part of the automation. This is not working like every third time when using my Apple TV.
The automation looks like this:
- id: '1631614592237'
  alias: Hue Sync Box aktivieren
  description: ''
  trigger:
  - platform: device
    device_id: 785ee3ab566d77d792ae95122733ab3d
    domain: media_player
    entity_id: media_player.wozi
    type: idle
  - platform: device
    device_id: 785ee3ab566d77d792ae95122733ab3d
    domain: media_player
    entity_id: media_player.wozi
    type: idle
    for:
      hours: 0
      minutes: 0
      seconds: 10
      milliseconds: 0
  condition:
  - condition: device
    type: is_on
    device_id: b3830cd7396acef86861954a86840eb9
    entity_id: remote.wohnzimmer
    domain: remote
  action:
  - device_id: 785ee3ab566d77d792ae95122733ab3d
    domain: huesyncbox
    entity_id: media_player.wozi
    type: sync_on
  mode: restart
  max: 10

I put a second trigger with a delay of 10 seconds as a workaround (to send the action a second time after 10 seconds if the first send did not went thru), that seems to work yesterday.
As I said before I think the action does not arrive at the sync box every time for me.

Any news on a permanent fix for this?
Thanks!

I get this issue a lot, It can be approximately every 30 seconds for periods, and then stops doing it for a while, then comes back again! It doesn't stop it working but it makes my log file somewhat busy!
Completely understand that it could very well be down to local network conditions (I have a lot of equipment on my network!) but would it be possible to add an option in a future version to change the poll interval if we want to? That way we can adjust it to something that works for us. I have no issue waiting 5-10 seconds for my lights to start syncing or change modes, but others may want it quicker. An option for the user to change this might be a way to solve this.
Thanks for the great component though, I was sending rest commands manually before and it was very hit and miss, this works so much better!!

Ow, sorry for the late reply. I somehow missed the 20 sept response.
@sparsons99 Since I am using the standard SCAN_INTERVAL thing in HA you might be able to override it configuration.yaml as documented here https://www.home-assistant.io/docs/configuration/platform_options/#scan-interval
Other option could be the "Disable polling" option introduced in HA 2021.6 (https://www.home-assistant.io/blog/2021/06/02/release-20216/#disable-polling-updates-on-any-integration) and manage your own update frequency.
I am planning to do some work on the integration during the upcoming holidays and will take a look at this.
However it would really help to get some logging of the traffic to the syncbox so if one of you could temporarily enable the logging by adding the section below to configuration.yaml and reproduce the issue that would help a lot. It helps me to see if the box returns an error, there is a timeout or maybe something else.
logger:
  default: info
  logs:
    huesyncbox: debug
    aiohuesyncbox: debug

@mvdwetering thank you for the suggestions, will have a look at those. Happy to test the logging. Will try it now and let you know what happens. Probably won't take long in my case!
As an example, this is what I see frequently in my log file:
2021-12-14 19:54:52 WARNING (MainThread) [homeassistant.components.media_player] Updating huesyncbox media_player took longer than the scheduled update interval 0:00:02
2021-12-14 19:55:22 WARNING (MainThread) [homeassistant.components.media_player] Updating huesyncbox media_player took longer than the scheduled update interval 0:00:02
2021-12-14 19:55:52 WARNING (MainThread) [homeassistant.components.media_player] Updating huesyncbox media_player took longer than the scheduled update interval 0:00:02
2021-12-14 19:56:22 WARNING (MainThread) [homeassistant.components.media_player] Updating huesyncbox media_player took longer than the scheduled update interval 0:00:02
2021-12-14 19:56:52 WARNING (MainThread) [homeassistant.components.media_player] Updating huesyncbox media_player took longer than the scheduled update interval 0:00:02
2021-12-14 19:57:22 WARNING (MainThread) [homeassistant.components.media_player] Updating huesyncbox media_player took longer than the scheduled update interval 0:00:02
2021-12-14 19:57:52 WARNING (MainThread) [homeassistant.components.media_player] Updating huesyncbox media_player took longer than the scheduled update interval 0:00:02
2021-12-14 19:58:22 WARNING (MainThread) [homeassistant.components.media_player] Updating huesyncbox media_player took longer than the scheduled update interval 0:00:02
2021-12-14 19:58:52 WARNING (MainThread) [homeassistant.components.media_player] Updating huesyncbox media_player took longer than the scheduled update interval 0:00:02
2021-12-14 19:59:22 WARNING (MainThread) [homeassistant.components.media_player] Updating huesyncbox media_player took longer than the scheduled update interval 0:00:02
2021-12-14 19:59:52 WARNING (MainThread) [homeassistant.components.media_player] Updating huesyncbox media_player took longer than the scheduled update interval 0:00:02
2021-12-14 20:00:22 WARNING (MainThread) [homeassistant.components.media_player] Updating huesyncbox media_player took longer than the scheduled update interval 0:00:02
2021-12-14 20:00:52 WARNING (MainThread) [homeassistant.components.media_player] Updating huesyncbox media_player took longer than the scheduled update interval 0:00:02
2021-12-14 20:01:22 WARNING (MainThread) [homeassistant.components.media_player] Updating huesyncbox media_player took longer than the scheduled update interval 0:00:02
2021-12-14 20:01:52 WARNING (MainThread) [homeassistant.components.media_player] Updating huesyncbox media_player took longer than the scheduled update interval 0:00:02
2021-12-14 20:02:22 WARNING (MainThread) [homeassistant.components.media_player] Updating huesyncbox media_player took longer than the scheduled update interval 0:00:02
2021-12-14 20:02:52 WARNING (MainThread) [homeassistant.components.media_player] Updating huesyncbox media_player took longer than the scheduled update interval 0:00:02
2021-12-14 20:03:22 WARNING (MainThread) [homeassistant.components.media_player] Updating huesyncbox media_player took longer than the scheduled update interval 0:00:02
2021-12-14 20:03:52 WARNING (MainThread) [homeassistant.components.media_player] Updating huesyncbox media_player took longer than the scheduled update interval 0:00:02
Not sure if that is entirely useful, although odd that it is exactly 30 seconds each time!

Ok, so I enabled logging and got this:
2021-12-14 20:49:29 DEBUG (MainThread) [aiohuesyncbox.huesyncbox] get, https://_<IP_ADDRESS>:443/api/v1, None
2021-12-14 20:49:29 INFO (MainThread) [charset_normalizer] ascii passed initial chaos probing. Mean measured chaos is 0.000000 %
2021-12-14 20:49:29 INFO (MainThread) [charset_normalizer] ascii should target any language(s) of ['Latin Based']
2021-12-14 20:49:29 INFO (MainThread) [charset_normalizer] We detected language [('English', 1.0), ('Dutch', 1.0), ('Indonesian', 1.0)] using ascii
2021-12-14 20:49:29 INFO (MainThread) [charset_normalizer] ascii is most likely the one. Stopping the process.
2021-12-14 20:49:31 WARNING (MainThread) [homeassistant.components.media_player] Updating huesyncbox media_player took longer than the scheduled update interval 0:00:02
2021-12-14 20:49:32 DEBUG (MainThread) [aiohuesyncbox.huesyncbox] 200, {"device":{"name":"Sync Box","deviceType":"HSB1","uniqueId":"C42996017DAC","apiLevel":7,"firmwareVersion":"1.7.4","buildNumber":681947148,"termsAgreed":true,"wifiState":"wan","ipAddress":"<IP_ADDRESS>","wifi":{"ssid":"Elmo","strength":3},"lastCheckedUpdate":"2021-12-14T10:00:23Z","updatableBuildNumber":696280590,"updatableFirmwareVersion":"1.8.3","update":{"autoUpdateEnabled":false,"autoUpdateTime":10},"ledMode":1,"action":"none","pushlink":"idle","capabilities":{"maxIrCodes":24,"maxPresets":16},"beta":false},"hue":{"bridgeUniqueId":"001788FFFE66CECE","bridgeIpAddress":"<IP_ADDRESS>","groupId":"216616cb-1ad0-4bca-9f61-f0f67e7cac16","groups":{"b2a8d4dd-282c-44d2-9652-6e9aaec0617d":{"name":"Living Room","numLights":1,"active":false},"61704bf9-869a-4332-b26f-43afce5c8d52":{"name":"Living room plus portable","numLights":7,"active":false},"216616cb-1ad0-4bca-9f61-f0f67e7cac16":{"name":"Living Room all","numLights":5,"active":false},"d36ff657-c7b5-492a-99d8-c5f9a572e9c1":{"name":"House","numLights":10,"active":false},"4db20ebb-de75-4ef2-ad1a-a748fbcd955a":{"name":"Back Garden beds","numLights":3,"active":false}},"connectionState":"connected"},"execution":{"mode":"passthrough","syncActive":false,"hdmiActive":true,"hdmiSource":"input1","hueTarget":"216616cb-1ad0-4bca-9f61-f0f67e7cac16","brightness":189,"lastSyncMode":"video","video":{"intensity":"moderate","backgroundLighting":false},"game":{"intensity":"intense","backgroundLighting":false},"music":{"intensity":"high","palette":"melancholicEnergetic"},"preset":null},"hdmi":{"input1":{"name":"Sky","type":"generic","status":"linked","lastSyncMode":"video"},"input2":{"name":"Chromecast","type":"generic","status":"plugged","lastSyncMode":"video"},"input3":{"name":"HDMI 3","type":"generic","status":"unplugged","lastSyncMode":"video"},"input4":{"name":"HDMI 4","type":"generic","status":"unplugged","lastSyncMode":"video"},"output":{"name":"HDMI Out","type":"generic","status":"linked","lastSyncMode":"video"},"contentSpecs":"3840 x 2160 @ 50000 - SDR","videoSyncSupported":true,"audioSyncSupported":false},"behavior":{"inactivePowersave":20,"cecPowersave":1,"usbPowersave":1,"hpdInputSwitch":1,"hpdOutputEnableMs":1500,"arcBypassMode":0,"forceDoviNative":0,"input1":{"cecInputSwitch":1,"linkAutoSync":0,"hdrMode":0},"input2":{"cecInputSwitch":1,"linkAutoSync":0,"hdrMode":0},"input3":{"cecInputSwitch":1,"linkAutoSync":0,"hdrMode":0},"input4":{"cecInputSwitch":1,"linkAutoSync":0,"hdrMode":0}},"ir":{"defaultCodes":true,"scan":{"scanning":false,"code":null,"codes":[]},"codes":{}},"registrations":{"2":{"appName":"Google","instanceName":"001788FFFE66CECE","role":"user","verified":true,"lastUsed":"2021-12-11T08:16:29Z","created":"2020-10-17T12:23:08Z"},"3":{"appName":"Home Assistant","instanceName":"Home","role":"user","verified":false,"lastUsed":"2021-12-14T20:49:32Z","created":"2021-01-24T18:16:57Z"},"4":{"appName":"Hue Sync Android","instanceName":"o1s","role":"user","verified":true,"lastUsed":"2021-12-11T21:37:55Z","created":"2021-10-09T17:48:09Z"},"1":{"appName":"curl","instanceName":"steveparsons99","role":"user","verified":false,"lastUsed":"2021-12-14T20:49:03Z","created":"2020-04-02T20:45:46Z"},"0":{"appName":"Hue Sync Android","instanceName":"beyond1","role":"admin","verified":true,"lastUsed":"2021-10-09T13:58:10Z","created":"2019-12-15T15:06:43Z"}},"presets":{}}
2021-12-14 20:49:32 INFO (MainThread) [charset_normalizer] ascii passed initial chaos probing. Mean measured chaos is 0.000000 %
2021-12-14 20:49:32 INFO (MainThread) [charset_normalizer] ascii should target any language(s) of ['Latin Based']
2021-12-14 20:49:32 INFO (MainThread) [charset_normalizer] We detected language [('English', 1.0), ('Dutch', 1.0), ('Italian', 1.0)] using ascii
2021-12-14 20:49:32 INFO (MainThread) [charset_normalizer] ascii is most likely the one. Stopping the process.
2021-12-14 20:49:33 DEBUG (MainThread) [aiohuesyncbox.huesyncbox] get, https://_<IP_ADDRESS>:443/api/v1, None
2021-12-14 20:49:33 DEBUG (MainThread) [aiohuesyncbox.huesyncbox] 200, {"device":{"name":"Sync Box","deviceType":"HSB1","uniqueId":"C42996017DAC","apiLevel":7,"firmwareVersion":"1.7.4","buildNumber":681947148,"termsAgreed":true,"wifiState":"wan","ipAddress":"<IP_ADDRESS>","wifi":{"ssid":"Elmo","strength":3},"lastCheckedUpdate":"2021-12-14T10:00:23Z","updatableBuildNumber":696280590,"updatableFirmwareVersion":"1.8.3","update":{"autoUpdateEnabled":false,"autoUpdateTime":10},"ledMode":1,"action":"none","pushlink":"idle","capabilities":{"maxIrCodes":24,"maxPresets":16},"beta":false},"hue":{"bridgeUniqueId":"001788FFFE66CECE","bridgeIpAddress":"<IP_ADDRESS>","groupId":"216616cb-1ad0-4bca-9f61-f0f67e7cac16","groups":{"b2a8d4dd-282c-44d2-9652-6e9aaec0617d":{"name":"Living Room","numLights":1,"active":false},"61704bf9-869a-4332-b26f-43afce5c8d52":{"name":"Living room plus portable","numLights":7,"active":false},"216616cb-1ad0-4bca-9f61-f0f67e7cac16":{"name":"Living Room all","numLights":5,"active":false},"d36ff657-c7b5-492a-99d8-c5f9a572e9c1":{"name":"House","numLights":10,"active":false},"4db20ebb-de75-4ef2-ad1a-a748fbcd955a":{"name":"Back Garden beds","numLights":3,"active":false}},"connectionState":"connected"},"execution":{"mode":"passthrough","syncActive":false,"hdmiActive":true,"hdmiSource":"input1","hueTarget":"216616cb-1ad0-4bca-9f61-f0f67e7cac16","brightness":189,"lastSyncMode":"video","video":{"intensity":"moderate","backgroundLighting":false},"game":{"intensity":"intense","backgroundLighting":false},"music":{"intensity":"high","palette":"melancholicEnergetic"},"preset":null},"hdmi":{"input1":{"name":"Sky","type":"generic","status":"linked","lastSyncMode":"video"},"input2":{"name":"Chromecast","type":"generic","status":"plugged","lastSyncMode":"video"},"input3":{"name":"HDMI 3","type":"generic","status":"unplugged","lastSyncMode":"video"},"input4":{"name":"HDMI 4","type":"generic","status":"unplugged","lastSyncMode":"video"},"output":{"name":"HDMI Out","type":"generic","status":"linked","lastSyncMode":"video"},"contentSpecs":"3840 x 2160 @ 50000 - SDR","videoSyncSupported":true,"audioSyncSupported":false},"behavior":{"inactivePowersave":20,"cecPowersave":1,"usbPowersave":1,"hpdInputSwitch":1,"hpdOutputEnableMs":1500,"arcBypassMode":0,"forceDoviNative":0,"input1":{"cecInputSwitch":1,"linkAutoSync":0,"hdrMode":0},"input2":{"cecInputSwitch":1,"linkAutoSync":0,"hdrMode":0},"input3":{"cecInputSwitch":1,"linkAutoSync":0,"hdrMode":0},"input4":{"cecInputSwitch":1,"linkAutoSync":0,"hdrMode":0}},"ir":{"defaultCodes":true,"scan":{"scanning":false,"code":null,"codes":[]},"codes":{}},"registrations":{"2":{"appName":"Google","instanceName":"001788FFFE66CECE","role":"user","verified":true,"lastUsed":"2021-12-11T08:16:29Z","created":"2020-10-17T12:23:08Z"},"3":{"appName":"Home Assistant","instanceName":"Home","role":"user","verified":false,"lastUsed":"2021-12-14T20:49:33Z","created":"2021-01-24T18:16:57Z"},"4":{"appName":"Hue Sync Android","instanceName":"o1s","role":"user","verified":true,"lastUsed":"2021-12-11T21:37:55Z","created":"2021-10-09T17:48:09Z"},"1":{"appName":"curl","instanceName":"steveparsons99","role":"user","verified":false,"lastUsed":"2021-12-14T20:49:32Z","created":"2020-04-02T20:45:46Z"},"0":{"appName":"Hue Sync Android","instanceName":"beyond1","role":"admin","verified":true,"lastUsed":"2021-10-09T13:58:10Z","created":"2019-12-15T15:06:43Z"}},"presets":{}}
Sorry if the formatting isn't great!

Me again! Just as a further update, I amended the poll interval to 5 seconds last night and I haven't had a single issue since. Appreciate that may not work for everyone, but potentially waiting 3 seconds longer for my lights to start syncing is not really an issue for me!

@sparsons99 What is  your setting for that? Can you post it here. I have the same issue

@florie1706  to be honest I just amended the config\custom_components\huesyncbox\media_player.py file as I couldn't find an easy way to do it.
Line 62 - SCAN_INTERVAL = timedelta(seconds=5)
This isn't the best way to do it as any updates to the component will overwrite this setting, but I did it mainly just to test it, and it's a very quick tweak to redo after an update if needed!

Thanks, that is what I needed for testing ;)

I am cleaning up old issues and see that this was still open. Since it is very old I will post a summary of the current state and close it.
In the just released v2.1.0 errors are only logged when multiple consecutive requests fail, so that should reduce the logspam.
Also meanwhile the polling interval has changed to 3 seconds instead of 2 (that was with v2.0.0)
And last, if someone still wants to change the interval I would suggest to do it the official way by disabling the "Enable polling for updates" option in the System Options of the integration. Then create an automation that triggers the updates on an interval to your liking. Basically like descibed here for the Ping integration but choose an entity from this integration (just one, not all, they will update together on every update)