StackOverflowError when calling ChartEntryModelProducer::setEntries()

How to reproduce
I called chartEntryModelProducer.setEntries() in my ViewModel and got a StackOverflowError.
There are only 76 entries in the list and I don't think the entry-count is the problem.
It works fine most of the time.
I'm calling setEntries() in someflow.mapLatest {}. Maybe it's some kind of sync problem between co-routines?
Observed behavior
Got this Exception:
FATAL EXCEPTION: DefaultDispatcher-worker-3
                                                                                Process: redacted, PID: 16197
                                                                                java.lang.StackOverflowError: stack size 1039KB
                                                                                at com.patrykandpatryk.vico.core.extension.NumberExtensionsKt.gcdWithImpl(NumberExtensions.kt:40)
                                                                                at com.patrykandpatryk.vico.core.extension.NumberExtensionsKt.gcdWithImpl(NumberExtensions.kt:38)
--- repeated many, many times ---
                                                                                at com.patrykandpatryk.vico.core.extension.NumberExtensionsKt.gcdWithImpl(NumberExtensions.kt:38)
                                                                                at com.patrykandpatryk.vico.core.extension.NumberExtensionsKt.gcdWithImpl(NumberExtensions.kt:40)
2023-12-21 14:55:38.619 16197-16226 AndroidRuntime          redacted		               E  	at com.patrykandpatryk.vico.core.extension.NumberExtensionsKt.gcdWithImpl(NumberExtensions.kt:38)
                                                                                at com.patrykandpatryk.vico.core.extension.NumberExtensionsKt.gcdWithImpl(NumberExtensions.kt:40)
                                                                                at com.patrykandpatryk.vico.core.extension.NumberExtensionsKt.gcdWithImpl(NumberExtensions.kt:38)
                                                                                at com.patrykandpatryk.vico.core.extension.NumberExtensionsKt.gcdWithImpl(NumberExtensions.kt:40)
                                                                                at com.patrykandpatryk.vico.core.extension.NumberExtensionsKt.gcdWithImpl(NumberExtensions.kt:40)
                                                                                at com.patrykandpatryk.vico.core.extension.NumberExtensionsKt.gcdWithImpl(NumberExtensions.kt:38)
                                                                                at com.patrykandpatryk.vico.core.extension.NumberExtensionsKt.gcdWith(NumberExtensions.kt:43)
                                                                                at com.patrykandpatryk.vico.core.entry.ChartEntryExtensionsKt.calculateXGcd(ChartEntryExtensions.kt:93)
                                                                                at com.patrykandpatryk.vico.core.entry.ChartEntryModelProducer.getInternalModel(ChartEntryModelProducer.kt:151)
                                                                                at com.patrykandpatryk.vico.core.entry.ChartEntryModelProducer.getInternalModel$default(ChartEntryModelProducer.kt:133)
                                                                                at com.patrykandpatryk.vico.core.entry.ChartEntryModelProducer.getModel(ChartEntryModelProducer.kt:158)
                                                                                at com.patrykandpatryk.vico.core.entry.ChartEntryModelProducer$UpdateReceiver.handleUpdate(ChartEntryModelProducer.kt:213)
                                                                                at com.patrykandpatryk.vico.core.entry.ChartEntryModelProducer.registerForUpdates(ChartEntryModelProducer.kt:190)
                                                                                at com.patrykandpatryk.vico.compose.chart.entry.ChartEntryModelExtensionsKt$collectAsState$1$1.invokeSuspend(ChartEntryModelExtensions.kt:116)
                                                                                at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:33)
                                                                                at kotlinx.coroutines.DispatchedTask.run(DispatchedTask.kt:108)
                                                                                at kotlinx.coroutines.scheduling.CoroutineScheduler.runSafely(CoroutineScheduler.kt:584)
                                                                                at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.executeTask(CoroutineScheduler.kt:793)
                                                                                at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.runWorker(CoroutineScheduler.kt:697)
                                                                                at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.run(CoroutineScheduler.kt:684)
                                                                                Suppressed: kotlinx.coroutines.internal.DiagnosticCoroutineContextException: [androidx.compose.ui.platform.MotionDurationScaleImpl@9ee80f6, androidx.compose.runtime.BroadcastFrameClock@a1c0cf7, StandaloneCoroutine{Cancelling}@7eef764, Dispatchers.Default]

Expected behavior
No crash, with new values in the chart.
Vico version(s)
Latest stable version
Android version(s)
14
Additional information
No response

Hello! Thanks for the report. The chart data is relevant here. Could you please share a set of x and y values for which the crash occurs? You could, for example, update your code to send a log message containing the x and y values before setEntries is invoked.

I struggle to reproduce it right now. I'll post the entries once, I get the StackOverflowError again.
Instead I get this error, even though there are no duplicate values:
FATAL EXCEPTION: DefaultDispatcher-worker-1
                                                                                Process: redacted, PID: 20412
                                                                                java.lang.IllegalArgumentException: The precision of the x values is too large. The maximum is two decimal places.
                                                                                at com.patrykandpatryk.vico.core.entry.ChartEntryExtensionsKt.calculateXGcd(ChartEntryExtensions.kt:94)
                                                                                at com.patrykandpatryk.vico.core.entry.ChartEntryModelProducer.getInternalModel(ChartEntryModelProducer.kt:151)
                                                                                at com.patrykandpatryk.vico.core.entry.ChartEntryModelProducer.getInternalModel$default(ChartEntryModelProducer.kt:133)
                                                                                at com.patrykandpatryk.vico.core.entry.ChartEntryModelProducer.getModel(ChartEntryModelProducer.kt:158)
                                                                                at com.patrykandpatryk.vico.core.entry.ChartEntryModelProducer$UpdateReceiver.handleUpdate(ChartEntryModelProducer.kt:213)
                                                                                at com.patrykandpatryk.vico.core.entry.ChartEntryModelProducer.registerForUpdates(ChartEntryModelProducer.kt:190)
                                                                                at com.patrykandpatryk.vico.compose.chart.entry.ChartEntryModelExtensionsKt$collectAsState$1$1.invokeSuspend(ChartEntryModelExtensions.kt:116)
                                                                                at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:33)
                                                                                at kotlinx.coroutines.DispatchedTask.run(DispatchedTask.kt:108)
                                                                                at kotlinx.coroutines.scheduling.CoroutineScheduler.runSafely(CoroutineScheduler.kt:584)
                                                                                at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.executeTask(CoroutineScheduler.kt:793)
                                                                                at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.runWorker(CoroutineScheduler.kt:697)
                                                                                at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.run(CoroutineScheduler.kt:684)
                                                                                Suppressed: kotlinx.coroutines.internal.DiagnosticCoroutineContextException: [androidx.compose.ui.platform.MotionDurationScaleImpl@e1a8da, androidx.compose.runtime.BroadcastFrameClock@423810b, StandaloneCoroutine{Cancelling}@df17be8, Dispatchers.Default]

Here are the values I put in setEntries():
precision-too-large-exception.txt
I suspect a concurrency problem, but don't know how to debug it further.

I wrote a test-case with the FloatEntries from my last comment. (I copied the internal implementation from Vico files, so I could test them):
ChartEntryExtensionsTest.kt.txt
There seems to be a bug in calculateXGcd(): The last FloatEntry causes the exception to incorrectly being thrown. If you comment it out, no exception is thrown. The x-value of that entry is unique up to the first three digits (864xx.x) which should be enough?
Sorry for mixing two different exceptions in one issue, hope it's ok.

Thanks for looking into this, @littleant! It’s not necessarily a deal-breaker that the first proposed solution causes the last test to fail. The GCD algorithm is in place not to detect excessive precision, but rather to determine the default x step. The zero check is present because an x step of zero would cause unexpected behavior. It happens to be the case that calculateXGcd produces such an x step for overly precise x values. Such x values can cause other issues too, and there already are instances in which they go undetected—perhaps a dedicated precision check should be added.
The round(2) solution could be added if it fixed the delta calculation. Unfortunately, from what I can tell, it doesn’t necessarily produce the desired result. While it works for 74176.98f - 46336.89f, it fails for 174176.98f - 146336.83f, where the result would have to be rounded down to be correct.
It does look like something has to be changed here. Since, as described above, calculateXGcd determines the default x step, removing the GCD search would constitute a regression. More specifically, the default scaling of charts would worsen. This isn’t optimal, but it does seem like less of an inconvenience than switching to Ints or Longs, which would make it impossible to use fractional x values, forcing Vico users to do more data processing. If calculateXGcd is removed, it might be possible to add it back once we switch from Floats to Doubles, which we plan on doing. I’ll discuss the matter with @Gowsky.
In the meantime, I suggest that you multiply your x values by 10 (for one decimal place) or, if that doesn’t help, by 100 (for whole numbers). You can divide them during formatting to have the right values displayed along x-axes.

A dedicated precision check would be a solution I think. It would assert that there are no values with a precision lower than 0.01. Afterwards you can define the minimum GCD to be 0.01, regardless of what you detect in calculateXGcd().
I agree, round(2) is not the solution here.
I think switching to Double would not solve the issue. It would just allow larger values until the same issue surfaces again. (You are just switching from 32bit to 64bit.)
Unless you keep the external API to only use Floats and immediately convert them to Doubles for internal use (e.g. in entryOf(). This may work, I don't know.
If you don't want to switch to Int or Long in the external API, you could convert to Longs in the internal API, since you already restrict the precision. e.g. with this conversion logic:

If x-value is of type Float, cast it to Double, multiply it by 100 and cast it to Longs for internal use.
If x-value is of type Double, multiply by 100 and cast it to Longs. (This could be a problem with higher values)
If x-value is of type Int, cast to Long and multiply by 100.
If x-value is of type Long, multiply by 100. (This could also lead to problems, if values near Long.MAX_VALUE are being used.)

I have added this logic in the hopes that it prevents exceptions. (I'm not sure if .toInt().toFloat() actually does anything except hiding fractional digits?):
.setEntries(entries.map { entry ->
    FloatEntry(x = (entry.x * 100f).toInt().toFloat(), y = entry.y)
})

Thanks for the input, @littleant! Regarding switching to Floats to Doubles, this problem would certainly reappear for some precision level, but what I had in mind is that Doubles might be precise enough to give us a reasonably high precision level that consistently works. We’d still need a precision check. As can be seen here, with Floats, even two decimal places can be problematic, and a limit of one decimal place would be a bit too restrictive. About chaining toInt and toFloat, this doesn’t do anything beyond removing all decimals. A slightly more concise option is floor(entry.x * 100f).
Vico 2.0.0 Alpha 6 introduces an improvement that is helpful here: when you set a custom x step, no GCD calculations are run. Thus, when the GCD algorithm fails due to precision issues, rather than transforming your data, you can simply explicitly specify the x step. For your data, getXStep = { 0.01f } could be added, and everything should work as expected. Of course, it would be optimal for the GCD algorithm not to fail in the first place. We’ll continue to look into this.

Vico 1.14.0 Beta 1 also includes the aforementioned improvement.


Can we have the Flux Source Controller point to a specific kube-api server?

Hi,
I have a kubernetes cluster set up with another kube-api server running in the cluster. I would like to deploy the source controller and the Flux CRDs pointing to this kube-api server. I was able to successfully create the CRDs. But I'm unable to point my source-controller to this kube-api server so it watches the gitrepository CR created in this server. Any pointers on how this can be achieved?
Thanks
Geeta

By setting a path to an alternative KubeConfig using the KUBECONFIG environment variable, this should be theoretically possible as it would overwrite in-cluster discovery.

Hi @hiddeco , I get this error when I set the KUBECONFIG variable:
{"level":"info","ts":"2023-03-20T11:49:12.580Z","logger":"controller-runtime.metrics","msg":"Metrics server is starting to listen","addr":":8080"} {"level":"info","ts":"2023-03-20T11:49:12.581Z","logger":"setup","msg":"starting manager"} {"level":"info","ts":"2023-03-20T11:49:12.582Z","msg":"Starting server","path":"/metrics","kind":"metrics","addr":"[::]:8080"} {"level":"info","ts":"2023-03-20T11:49:12.582Z","msg":"Starting server","kind":"health probe","addr":"[::]:9440"} I0320 11:49:12.683467       1 leaderelection.go:248] attempting to acquire leader lease apix/source-controller-leader-election... E0320 11:49:12.726936       1 leaderelection.go:334] error initially creating leader election record: the server could not find the requested resource (post leases.coordination.k8s.io) E0320 11:49:20.951115       1 leaderelection.go:334] error initially creating leader election record: the server could not find the requested resource (post leases.coordination.k8s.io) E0320 11:49:28.723806       1 leaderelection.go:334] error initially creating leader election record: the server could not find the requested resource (post leases.coordination.k8s.io) E0320 11:49:37.539840       1 leaderelection.go:334] error initially creating leader election record: the server could not find the requested resource (post leases.coordination.k8s.io)

I figured out why leases.coordination.k8s.io was not found. I fixed that, but I still get this error: E0320 13:54:04.519567       1 leaderelection.go:334] error initially creating leader election record: namespaces "apix" not found
How do I handle this?

By creating the namespace in which it tries to put the lock?

apix namespace already exists in the kubernetes cluster on which the source-controller is deployed. Does it need this namespace in the kube-apiserver that the source controller is pointing to?

Yes, because that's the only thing it sees when you use a custom KubeConfig. It's detached from the cluster it's running in.

ok, and would it work fine if the kube-api server that it is pointing to does not have the capability to schedule pods?

I'm curious what is the goal of running Flux this way? We usually attach the KubeConfig at the Kustomization level, so the resources that are created are hosted on the target cluster.
You can target a remote cluster without funneling all of Flux to that cluster. Typically the sources are hosted on the cluster where Flux is installed. Here is an example of that:
https://fluxcd.io/flux/components/kustomize/kustomization/#remote-clusters--cluster-api

I'm going to go ahead and close this, please let us know if you still have a question.


Skills Display: Name is shown over Contact button on small screens when project name is a certain length

:+1:


When I try to do anything, the server crashes

Is there an existing issue for this?

[X] I have searched the existing issues

Version of Corteza
No response
Current Behavior
Here's a sample of all of the timeouts. After many timeouts, the server becomes unreachable via browser (although nginx is still reachable)
nginx logs filtered by timeouts
nginx-proxy             | nginx.1     | 2023/07/06 13:08:34 [error] 64#64: *1019 upstream timed out (110: Connection timed out) while reading response header from upstream, client: CENSORED_CLIENT, server: CENSORED_DOMAIN, request: "POST /api/compose/namespace/304789571474829316/module/312906757590482948/record/344527799173791750 HTTP/2.0", upstream: "http://<IP_ADDRESS>:80/api/compose/namespace/304789571474829316/module/312906757590482948/record/344527799173791750", host: "CENSORED_DOMAIN", referrer: "https://CENSORED_DOMAIN/compose/ns/crm/pages/312917135724642308?recordID=344527799173791750&recordPageID=312917095962640388"
nginx-proxy             | nginx.1     | 2023/07/06 13:11:54 [error] 63#63: *1278 upstream timed out (110: Connection timed out) while reading response header from upstream, client: CENSORED_CLIENT, server: CENSORED_DOMAIN, request: "POST /api/compose/namespace/304789571474829316/module/312906757590482948/record/1640804756936984469 HTTP/2.0", upstream: "http://<IP_ADDRESS>:80/api/compose/namespace/304789571474829316/module/312906757590482948/record/1640804756936984469", host: "CENSORED_DOMAIN", referrer: "https://CENSORED_DOMAIN/compose/ns/crm/pages/312917135724642308?recordID=1640804756936984469&recordPageID=312917095962640388"
nginx-proxy             | nginx.1     | 2023/07/06 13:16:16 [error] 64#64: *1627 upstream timed out (110: Connection timed out) while reading response header from upstream, client: CENSORED_CLIENT, server: CENSORED_DOMAIN, request: "POST /api/compose/namespace/304789571474829316/module/312906757590482948/record/1640804598786556976 HTTP/2.0", upstream: "http://<IP_ADDRESS>:80/api/compose/namespace/304789571474829316/module/312906757590482948/record/1640804598786556976", host: "CENSORED_DOMAIN", referrer: "https://CENSORED_DOMAIN/compose/ns/crm/pages/312917135724642308?recordID=1640804598786556976&recordPageID=312917095962640388"
nginx-proxy             | nginx.1     | 2023/07/06 13:19:14 [error] 63#63: *1662 upstream timed out (110: Connection timed out) while reading response header from upstream, client: CENSORED_CLIENT, server: CENSORED_DOMAIN, request: "POST /api/compose/namespace/304789571474829316/module/312906757590482948/record/335098533331890178 HTTP/2.0", upstream: "http://<IP_ADDRESS>:80/api/compose/namespace/304789571474829316/module/312906757590482948/record/335098533331890178", host: "CENSORED_DOMAIN", referrer: "https://CENSORED_DOMAIN/compose/ns/crm/pages/312917135724642308?recordID=335098533331890178&recordPageID=312917095962640388"
nginx-proxy             | nginx.1     | 2023/07/06 13:20:53 [error] 64#64: *1714 upstream timed out (110: Connection timed out) while reading response header from upstream, client: CENSORED_CLIENT, server: CENSORED_DOMAIN, request: "POST /api/compose/namespace/304789571474829316/module/312906757590482948/record/1640804573352298319 HTTP/2.0", upstream: "http://<IP_ADDRESS>:80/api/compose/namespace/304789571474829316/module/312906757590482948/record/1640804573352298319", host: "CENSORED_DOMAIN", referrer: "https://CENSORED_DOMAIN/compose/ns/crm/pages/312917135724642308?recordID=1640804573352298319&recordPageID=312917095962640388"
nginx-proxy             | nginx.1     | 2023/07/06 13:22:49 [error] 63#63: *1759 upstream timed out (110: Connection timed out) while reading response header from upstream, client: CENSORED_CLIENT, server: CENSORED_DOMAIN, request: "POST /api/compose/namespace/304789571474829316/module/312906757590482948/record/344527799173791750 HTTP/2.0", upstream: "http://<IP_ADDRESS>:80/api/compose/namespace/304789571474829316/module/312906757590482948/record/344527799173791750", host: "CENSORED_DOMAIN", referrer: "https://CENSORED_DOMAIN/compose/ns/crm/pages/312917135724642308?recordID=344527799173791750&recordPageID=312917095962640388"
nginx-proxy             | nginx.1     | 2023/07/06 13:50:54 [error] 63#63: *2434 upstream timed out (110: Connection timed out) while reading response header from upstream, client: CENSORED_CLIENT, server: CENSORED_DOMAIN, request: "POST /api/compose/namespace/304789571474829316/module/312906757590482948/record/1640804598786556976 HTTP/2.0", upstream: "http://<IP_ADDRESS>:80/api/compose/namespace/304789571474829316/module/312906757590482948/record/1640804598786556976", host: "CENSORED_DOMAIN", referrer: "https://CENSORED_DOMAIN/compose/ns/crm/pages/312917135724642308?recordID=1640804598786556976&recordPageID=312917095962640388"
nginx-proxy             | nginx.1     | 2023/07/06 13:52:48 [error] 64#64: *2593 upstream timed out (110: Connection timed out) while reading response header from upstream, client: CENSORED_CLIENT, server: CENSORED_DOMAIN, request: "POST /api/compose/namespace/304789571474829316/module/312906757590482948/record/1640804598786556976 HTTP/2.0", upstream: "http://<IP_ADDRESS>:80/api/compose/namespace/304789571474829316/module/312906757590482948/record/1640804598786556976", host: "CENSORED_DOMAIN", referrer: "https://CENSORED_DOMAIN/compose/ns/crm/pages/312917135724642308?recordID=1640804598786556976&recordPageID=312917095962640388"
nginx-proxy             | nginx.1     | 2023/07/06 13:57:15 [error] 63#63: *2688 upstream timed out (110: Connection timed out) while reading response header from upstream, client: CENSORED_CLIENT, server: CENSORED_DOMAIN, request: "POST /api/compose/namespace/304789571474829316/module/312906757590482948/record/1640804598786556976 HTTP/2.0", upstream: "http://<IP_ADDRESS>:80/api/compose/namespace/304789571474829316/module/312906757590482948/record/1640804598786556976", host: "CENSORED_DOMAIN", referrer: "https://CENSORED_DOMAIN/compose/ns/crm/pages/312917135724642308?recordID=1640804598786556976&recordPageID=312917095962640388"
nginx-proxy             | nginx.1     | 2023/07/06 13:59:06 [error] 63#63: *2776 upstream timed out (110: Connection timed out) while reading response header from upstream, client: CENSORED_CLIENT, server: CENSORED_DOMAIN, request: "POST /api/compose/namespace/304789571474829316/module/312906757590482948/record/1640804598786556976 HTTP/2.0", upstream: "http://<IP_ADDRESS>:80/api/compose/namespace/304789571474829316/module/312906757590482948/record/1640804598786556976", host: "CENSORED_DOMAIN", referrer: "https://CENSORED_DOMAIN/compose/ns/crm/pages/312917135724642308?recordID=1640804598786556976&recordPageID=312917095962640388"
nginx-proxy             | nginx.1     | 2023/07/06 14:00:26 [error] 63#63: *2776 upstream timed out (110: Connection timed out) while reading response header from upstream, client: CENSORED_CLIENT, server: CENSORED_DOMAIN, request: "POST /api/compose/namespace/304789571474829316/module/312906757590482948/record/1640804598786556976 HTTP/2.0", upstream: "http://<IP_ADDRESS>:80/api/compose/namespace/304789571474829316/module/312906757590482948/record/1640804598786556976", host: "CENSORED_DOMAIN", referrer: "https://CENSORED_DOMAIN/compose/ns/crm/pages/312917135724642308?recordID=1640804598786556976&recordPageID=312917095962640388"
nginx-proxy             | nginx.1     | 2023/07/06 14:48:13 [error] 63#63: *5383 upstream timed out (110: Connection timed out) while reading response header from upstream, client: CENSORED_CLIENT, server: CENSORED_DOMAIN, request: "POST /api/compose/namespace/304789571474829316/module/312906757590482948/record/1640804598786556976 HTTP/2.0", upstream: "http://<IP_ADDRESS>:80/api/compose/namespace/304789571474829316/module/312906757590482948/record/1640804598786556976", host: "CENSORED_DOMAIN", referrer: "https://CENSORED_DOMAIN/compose/ns/crm/pages/312917135724642308?recordID=1640804598786556976&recordPageID=312917095962640388"
nginx-proxy             | nginx.1     | 2023/07/06 14:57:43 [error] 63#63: *5744 upstream timed out (110: Connection timed out) while reading response header from upstream, client: CENSORED_CLIENT, server: CENSORED_DOMAIN, request: "POST /api/compose/namespace/304789571474829316/module/312906757590482948/record/ HTTP/2.0", upstream: "http://<IP_ADDRESS>:80/api/compose/namespace/304789571474829316/module/312906757590482948/record/", host: "CENSORED_DOMAIN", referrer: "https://CENSORED_DOMAIN/compose/ns/crm/pages/312917095962640388/record"
nginx-proxy             | nginx.1     | 2023/07/06 15:01:14 [error] 64#64: *5871 upstream timed out (110: Connection timed out) while reading response header from upstream, client: CENSORED_CLIENT, server: CENSORED_DOMAIN, request: "POST /api/compose/namespace/304789571474829316/module/312906757590482948/record/344648651483664386 HTTP/2.0", upstream: "http://<IP_ADDRESS>:80/api/compose/namespace/304789571474829316/module/312906757590482948/record/344648651483664386", host: "CENSORED_DOMAIN", referrer: "https://CENSORED_DOMAIN/compose/ns/crm/pages/312917095962640388/record/344648651483664386/edit"
nginx-proxy             | nginx.1     | 2023/07/06 15:27:53 [error] 64#64: *7348 upstream timed out (110: Connection timed out) while reading response header from upstream, client: CENSORED_CLIENT, server: CENSORED_DOMAIN, request: "POST /api/compose/namespace/304789571474829316/module/312906757590482948/record/1640804756936984469 HTTP/2.0", upstream: "http://<IP_ADDRESS>:80/api/compose/namespace/304789571474829316/module/312906757590482948/record/1640804756936984469", host: "CENSORED_DOMAIN", referrer: "https://CENSORED_DOMAIN/compose/ns/crm/pages/312917135724642308?recordID=1640804756936984469&recordPageID=312917095962640388"
nginx-proxy             | nginx.1     | 2023/07/06 16:25:47 [error] 63#63: *10467 upstream timed out (110: Connection timed out) while reading response header from upstream, client: CENSORED_CLIENT, server: CENSORED_DOMAIN, request: "PUT /api/automation/workflows/330037181382918150 HTTP/2.0", upstream: "http://<IP_ADDRESS>:80/api/automation/workflows/330037181382918150", host: "CENSORED_DOMAIN", referrer: "https://CENSORED_DOMAIN/workflow/330037181382918150/edit"
nginx-proxy             | nginx.1     | 2023/07/06 16:28:03 [error] 64#64: *10887 upstream timed out (110: Connection timed out) while reading response header from upstream, client: CENSORED_CLIENT, server: CENSORED_DOMAIN, request: "PUT /api/automation/workflows/330037181382918150 HTTP/2.0", upstream: "http://<IP_ADDRESS>:80/api/automation/workflows/330037181382918150", host: "CENSORED_DOMAIN", referrer: "https://CENSORED_DOMAIN/workflow/330037181382918150/edit"
nginx-proxy             | nginx.1     | 2023/07/06 16:38:58 [error] 64#64: *11296 upstream timed out (110: Connection timed out) while reading response header from upstream, client: CENSORED_CLIENT, server: CENSORED_DOMAIN, request: "POST /api/compose/namespace/304789571474829316/module/312906757590482948/record/1640804923601847326 HTTP/2.0", upstream: "http://<IP_ADDRESS>:80/api/compose/namespace/304789571474829316/module/312906757590482948/record/1640804923601847326", host: "CENSORED_DOMAIN", referrer: "https://CENSORED_DOMAIN/compose/ns/crm/pages/312917135724642308?recordID=1640804923601847326&recordPageID=312917095962640388"
nginx-proxy             | nginx.1     | 2023/07/06 16:52:06 [error] 64#64: *11892 upstream timed out (110: Connection timed out) while reading response header from upstream, client: CENSORED_CLIENT, server: CENSORED_DOMAIN, request: "POST /auth/login HTTP/2.0", upstream: "http://<IP_ADDRESS>:80/auth/login", host: "CENSORED_DOMAIN", referrer: "https://CENSORED_DOMAIN/auth/login"
nginx-proxy             | nginx.1     | 2023/07/06 16:52:31 [error] 64#64: *11895 upstream timed out (110: Connection timed out) while reading response header from upstream, client: CENSORED_CLIENT, server: CENSORED_DOMAIN, request: "POST /auth/login HTTP/2.0", upstream: "http://<IP_ADDRESS>:80/auth/login", host: "CENSORED_DOMAIN", referrer: "https://CENSORED_DOMAIN/auth/login"
nginx-proxy             | nginx.1     | 2023/07/06 16:54:05 [error] 63#63: *11951 upstream timed out (110: Connection timed out) while reading response header from upstream, client: CENSORED_CLIENT, server: CENSORED_DOMAIN, request: "POST /auth/login HTTP/2.0", upstream: "http://<IP_ADDRESS>:80/auth/login", host: "CENSORED_DOMAIN", referrer: "https://CENSORED_DOMAIN/auth/login"

The last 100 lines of corteza-server logs
{"level":"error","ts":1688662351.7009053,"logger":"websocket.session","msg":"read failure","id":"344660206388531202","error":"websocket read failed: websocket: close 1006 (abnormal closure): unexpected EOF"}
{"level":"info","ts":1688662351.7009664,"logger":"websocket.session","msg":"disconnected","id":"344660206388531202"}
{"level":"info","ts":1688662351.7011197,"logger":"http.rest","msg":"HTTP response GET /api/websocket","requestID":"9478ee686179/Nc6uRhlTCI-007764","method":"GET","path":"/api/websocket","status":0,"size":0,"duration":60.000355466}
{"level":"error","ts":1688662352.1067288,"logger":"websocket.session","msg":"read failure","id":"344660207059619842","error":"websocket read failed: websocket: close 1006 (abnormal closure): unexpected EOF"}
{"level":"info","ts":1688662352.106793,"logger":"websocket.session","msg":"disconnected","id":"344660207059619842"}
{"level":"info","ts":1688662352.1069431,"logger":"http.rest","msg":"HTTP response GET /api/websocket","requestID":"9478ee686179/Nc6uRhlTCI-007765","method":"GET","path":"/api/websocket","status":0,"size":0,"duration":59.99995319}
{"level":"error","ts":1688662353.548706,"logger":"websocket.session","msg":"read failure","id":"344660209475538946","error":"websocket read failed: websocket: close 1006 (abnormal closure): unexpected EOF"}
{"level":"info","ts":1688662353.5487726,"logger":"websocket.session","msg":"disconnected","id":"344660209475538946"}
{"level":"info","ts":1688662353.5489259,"logger":"http.rest","msg":"HTTP response GET /api/websocket","requestID":"9478ee686179/Nc6uRhlTCI-007766","method":"GET","path":"/api/websocket","status":0,"size":0,"duration":60.00202864}
{"level":"info","ts":1688662355.715381,"logger":"http.rest","msg":"HTTP request GET /api/websocket","requestID":"9478ee686179/Nc6uRhlTCI-007776","method":"GET","path":"/api/websocket","size":0,"remote":"REMOTE_CENSORED"}
{"level":"debug","ts":1688662355.7363894,"logger":"websocket.session","msg":"authenticated","id":"344660313779490818","userID":"336419858830893061","roles":[]}
{"level":"info","ts":1688662356.1350324,"logger":"http.rest","msg":"HTTP request GET /api/websocket","requestID":"9478ee686179/Nc6uRhlTCI-007777","method":"GET","path":"/api/websocket","size":0,"remote":"REMOTE_CENSORED"}
{"level":"debug","ts":1688662356.1680405,"logger":"websocket.session","msg":"authenticated","id":"344660314484133890","userID":"336241579285061637","roles":[]}
{"level":"info","ts":1688662356.6924243,"logger":"http.rest","msg":"HTTP request GET /api/websocket","requestID":"9478ee686179/Nc6uRhlTCI-007778","method":"GET","path":"/api/websocket","size":0,"remote":"REMOTE_CENSORED"}
{"level":"debug","ts":1688662356.7257707,"logger":"websocket.session","msg":"authenticated","id":"344660315423657986","userID":"326967205482725381","roles":[]}
{"level":"error","ts":1688662360.1547723,"logger":"websocket.session","msg":"read failure","id":"344660220548501506","error":"websocket read failed: websocket: close 1006 (abnormal closure): unexpected EOF"}
{"level":"info","ts":1688662360.15484,"logger":"websocket.session","msg":"disconnected","id":"344660220548501506"}
{"level":"info","ts":1688662360.154996,"logger":"http.rest","msg":"HTTP response GET /api/websocket","requestID":"9478ee686179/Nc6uRhlTCI-007767","method":"GET","path":"/api/websocket","status":0,"size":0,"duration":60.007630637}
{"level":"error","ts":1688662362.7629251,"logger":"websocket.session","msg":"read failure","id":"344660224927354882","error":"websocket read failed: websocket: close 1006 (abnormal closure): unexpected EOF"}
{"level":"info","ts":1688662362.7629945,"logger":"websocket.session","msg":"disconnected","id":"344660224927354882"}
{"level":"info","ts":1688662362.7631545,"logger":"http.rest","msg":"HTTP response GET /api/websocket","requestID":"9478ee686179/Nc6uRhlTCI-007768","method":"GET","path":"/api/websocket","status":0,"size":0,"duration":60.0038799}
{"level":"info","ts":1688662364.108281,"logger":"http.rest","msg":"HTTP request GET /api/websocket","requestID":"9478ee686179/Nc6uRhlTCI-007779","method":"GET","path":"/api/websocket","size":0,"remote":"REMOTE_CENSORED"}
{"level":"debug","ts":1688662364.1326802,"logger":"websocket.session","msg":"authenticated","id":"344660327855575042","userID":"1614689468684437026","roles":[]}
{"level":"info","ts":1688662366.7815554,"logger":"http.rest","msg":"HTTP request GET /api/websocket","requestID":"9478ee686179/Nc6uRhlTCI-007780","method":"GET","path":"/api/websocket","size":0,"remote":"REMOTE_CENSORED"}
{"level":"debug","ts":1688662366.8194764,"logger":"websocket.session","msg":"authenticated","id":"344660332351868930","userID":"334217880621051906","roles":[]}
{"level":"error","ts":1688662371.133434,"logger":"websocket.session","msg":"read failure","id":"344660238969884674","error":"websocket read failed: websocket: close 1006 (abnormal closure): unexpected EOF"}
{"level":"info","ts":1688662371.1335092,"logger":"websocket.session","msg":"disconnected","id":"344660238969884674"}
{"level":"info","ts":1688662371.1336656,"logger":"http.rest","msg":"HTTP response GET /api/websocket","requestID":"9478ee686179/Nc6uRhlTCI-007769","method":"GET","path":"/api/websocket","status":0,"size":0,"duration":60.007630417}
{"level":"info","ts":1688662375.1169598,"logger":"http.rest","msg":"HTTP request GET /api/websocket","requestID":"9478ee686179/Nc6uRhlTCI-007781","method":"GET","path":"/api/websocket","size":0,"remote":"REMOTE_CENSORED"}
{"level":"debug","ts":1688662375.1365325,"logger":"websocket.session","msg":"authenticated","id":"344660346327289858","userID":"1614689468684437026","roles":[]}
{"level":"error","ts":1688662376.7801154,"logger":"websocket.session","msg":"read failure","id":"344660248449011714","error":"websocket read failed: websocket: close 1006 (abnormal closure): unexpected EOF"}
{"level":"info","ts":1688662376.7801862,"logger":"websocket.session","msg":"disconnected","id":"344660248449011714"}
{"level":"info","ts":1688662376.7803564,"logger":"http.rest","msg":"HTTP response GET /api/websocket","requestID":"9478ee686179/Nc6uRhlTCI-007770","method":"GET","path":"/api/websocket","status":0,"size":0,"duration":60.0061797}
{"level":"info","ts":1688662380.7959085,"logger":"http.rest","msg":"HTTP request GET /api/websocket","requestID":"9478ee686179/Nc6uRhlTCI-007782","method":"GET","path":"/api/websocket","size":0,"remote":"REMOTE_CENSORED"}
{"level":"debug","ts":1688662380.8331013,"logger":"websocket.session","msg":"authenticated","id":"344660355856748546","userID":"304789834122149892","roles":[]}
{"level":"info","ts":1688662385.1997988,"logger":"http.rest","msg":"HTTP request POST /auth/login","requestID":"9478ee686179/Nc6uRhlTCI-007783","method":"POST","path":"/auth/login","size":202,"remote":"REMOTE_CENSORED"}
{"level":"debug","ts":1688662385.201446,"logger":"auth","msg":"handling request","url":"/auth/login","method":"POST"}
{"level":"error","ts":1688662386.7138119,"logger":"websocket.session","msg":"read failure","id":"344660265125564418","error":"websocket read failed: websocket: close 1006 (abnormal closure): unexpected EOF"}
{"level":"info","ts":1688662386.7138734,"logger":"websocket.session","msg":"disconnected","id":"344660265125564418"}
{"level":"info","ts":1688662386.7140107,"logger":"http.rest","msg":"HTTP response GET /api/websocket","requestID":"9478ee686179/Nc6uRhlTCI-007771","method":"GET","path":"/api/websocket","status":0,"size":0,"duration":60.001041115}
{"level":"info","ts":1688662387.7238019,"logger":"http.rest","msg":"HTTP request GET /api/compose/namespace/304789571474829316/module/312906757590482948/record/","requestID":"9478ee686179/Nc6uRhlTCI-007784","method":"GET","path":"/api/compose/namespace/304789571474829316/module/312906757590482948/record/","size":0,"remote":"REMOTE_CENSORED"}
{"level":"info","ts":1688662387.735349,"logger":"http.rest","msg":"HTTP response GET /api/compose/namespace/304789571474829316/module/312906757590482948/record/","requestID":"9478ee686179/Nc6uRhlTCI-007784","method":"GET","path":"/api/compose/namespace/304789571474829316/module/312906757590482948/record/","status":200,"size":463,"duration":0.011496499}
{"level":"error","ts":1688662389.789671,"logger":"websocket.session","msg":"read failure","id":"344660270276169730","error":"websocket read failed: websocket: close 1006 (abnormal closure): unexpected EOF"}
{"level":"info","ts":1688662389.7897334,"logger":"websocket.session","msg":"disconnected","id":"344660270276169730"}
{"level":"info","ts":1688662389.789872,"logger":"http.rest","msg":"HTTP response GET /api/websocket","requestID":"9478ee686179/Nc6uRhlTCI-007773","method":"GET","path":"/api/websocket","status":0,"size":0,"duration":60.001532005}
{"level":"info","ts":1688662390.739589,"logger":"http.rest","msg":"HTTP request GET /api/websocket","requestID":"9478ee686179/Nc6uRhlTCI-007785","method":"GET","path":"/api/websocket","size":0,"remote":"REMOTE_CENSORED"}
{"level":"debug","ts":1688662390.767266,"logger":"websocket.session","msg":"authenticated","id":"344660372533301250","userID":"336419858830893061","roles":[]}
{"level":"info","ts":1688662393.7914348,"logger":"http.rest","msg":"HTTP request GET /api/websocket","requestID":"9478ee686179/Nc6uRhlTCI-007786","method":"GET","path":"/api/websocket","size":0,"remote":"REMOTE_CENSORED"}
{"level":"debug","ts":1688662393.8277519,"logger":"websocket.session","msg":"authenticated","id":"344660377667129346","userID":"334217880621051906","roles":[]}
{"level":"error","ts":1688662415.73194,"logger":"websocket.session","msg":"read failure","id":"344660313779490818","error":"websocket read failed: websocket: close 1006 (abnormal closure): unexpected EOF"}
{"level":"info","ts":1688662415.7320106,"logger":"websocket.session","msg":"disconnected","id":"344660313779490818"}
{"level":"info","ts":1688662415.732185,"logger":"http.rest","msg":"HTTP response GET /api/websocket","requestID":"9478ee686179/Nc6uRhlTCI-007776","method":"GET","path":"/api/websocket","status":0,"size":0,"duration":60.016748589}
{"level":"error","ts":1688662416.1347895,"logger":"websocket.session","msg":"read failure","id":"344660314484133890","error":"websocket read failed: websocket: close 1006 (abnormal closure): unexpected EOF"}
{"level":"info","ts":1688662416.134861,"logger":"websocket.session","msg":"disconnected","id":"344660314484133890"}
{"level":"info","ts":1688662416.1350448,"logger":"http.rest","msg":"HTTP response GET /api/websocket","requestID":"9478ee686179/Nc6uRhlTCI-007777","method":"GET","path":"/api/websocket","status":0,"size":0,"duration":59.999958134}
{"level":"error","ts":1688662416.6933746,"logger":"websocket.session","msg":"read failure","id":"344660315423657986","error":"websocket read failed: websocket: close 1006 (abnormal closure): unexpected EOF"}
{"level":"info","ts":1688662416.693436,"logger":"websocket.session","msg":"disconnected","id":"344660315423657986"}
{"level":"info","ts":1688662416.6936088,"logger":"http.rest","msg":"HTTP response GET /api/websocket","requestID":"9478ee686179/Nc6uRhlTCI-007778","method":"GET","path":"/api/websocket","status":0,"size":0,"duration":60.001128411}
{"level":"info","ts":1688662419.7186167,"logger":"http.rest","msg":"HTTP request GET /api/websocket","requestID":"9478ee686179/Nc6uRhlTCI-007787","method":"GET","path":"/api/websocket","size":0,"remote":"REMOTE_CENSORED"}
{"level":"debug","ts":1688662419.742841,"logger":"websocket.session","msg":"authenticated","id":"344660421153673218","userID":"336419858830893061","roles":[]}
{"level":"info","ts":1688662419.8120575,"logger":"http.rest","msg":"HTTP request GET /api/websocket","requestID":"9478ee686179/Nc6uRhlTCI-007788","method":"GET","path":"/api/websocket","size":0,"remote":"REMOTE_CENSORED"}
{"level":"debug","ts":1688662419.8376203,"logger":"websocket.session","msg":"authenticated","id":"344660421321445378","userID":"326967205482725381","roles":[]}
{"level":"info","ts":1688662420.10356,"logger":"http.rest","msg":"HTTP request GET /api/websocket","requestID":"9478ee686179/Nc6uRhlTCI-007789","method":"GET","path":"/api/websocket","size":0,"remote":"REMOTE_CENSORED"}
{"level":"debug","ts":1688662420.1371193,"logger":"websocket.session","msg":"authenticated","id":"344660421807984642","userID":"336241579285061637","roles":[]}
{"level":"error","ts":1688662424.1162667,"logger":"websocket.session","msg":"read failure","id":"344660327855575042","error":"websocket read failed: websocket: close 1006 (abnormal closure): unexpected EOF"}
{"level":"info","ts":1688662424.1163316,"logger":"websocket.session","msg":"disconnected","id":"344660327855575042"}
{"level":"info","ts":1688662424.1164856,"logger":"http.rest","msg":"HTTP response GET /api/websocket","requestID":"9478ee686179/Nc6uRhlTCI-007779","method":"GET","path":"/api/websocket","status":0,"size":0,"duration":60.008145785}
{"level":"error","ts":1688662426.7848196,"logger":"websocket.session","msg":"read failure","id":"344660332351868930","error":"websocket read failed: websocket: close 1006 (abnormal closure): unexpected EOF"}
{"level":"info","ts":1688662426.7848954,"logger":"websocket.session","msg":"disconnected","id":"344660332351868930"}
{"level":"info","ts":1688662426.7850704,"logger":"http.rest","msg":"HTTP response GET /api/websocket","requestID":"9478ee686179/Nc6uRhlTCI-007780","method":"GET","path":"/api/websocket","status":0,"size":0,"duration":60.003454117}
{"level":"info","ts":1688662428.119302,"logger":"http.rest","msg":"HTTP request GET /api/websocket","requestID":"9478ee686179/Nc6uRhlTCI-007790","method":"GET","path":"/api/websocket","size":0,"remote":"REMOTE_CENSORED"}
{"level":"debug","ts":1688662428.1365724,"logger":"websocket.session","msg":"authenticated","id":"344660435246534658","userID":"1614689468684437026","roles":[]}
{"level":"info","ts":1688662430.9113603,"logger":"http.rest","msg":"HTTP request GET /api/websocket","requestID":"9478ee686179/Nc6uRhlTCI-007791","method":"GET","path":"/api/websocket","size":0,"remote":"REMOTE_CENSORED"}
{"level":"debug","ts":1688662430.9544196,"logger":"websocket.session","msg":"authenticated","id":"344660439944155138","userID":"334217880621051906","roles":[]}
{"level":"error","ts":1688662435.1255715,"logger":"websocket.session","msg":"read failure","id":"344660346327289858","error":"websocket read failed: websocket: close 1006 (abnormal closure): unexpected EOF"}
{"level":"info","ts":1688662435.125634,"logger":"websocket.session","msg":"disconnected","id":"344660346327289858"}
{"level":"info","ts":1688662435.1258152,"logger":"http.rest","msg":"HTTP response GET /api/websocket","requestID":"9478ee686179/Nc6uRhlTCI-007781","method":"GET","path":"/api/websocket","status":0,"size":0,"duration":60.008798226}
{"level":"info","ts":1688662439.1358902,"logger":"http.rest","msg":"HTTP request GET /api/websocket","requestID":"9478ee686179/Nc6uRhlTCI-007792","method":"GET","path":"/api/websocket","size":0,"remote":"REMOTE_CENSORED"}
{"level":"debug","ts":1688662439.1523616,"logger":"websocket.session","msg":"authenticated","id":"344660453735026690","userID":"1614689468684437026","roles":[]}
{"level":"error","ts":1688662440.801408,"logger":"websocket.session","msg":"read failure","id":"344660355856748546","error":"websocket read failed: websocket: close 1006 (abnormal closure): unexpected EOF"}
{"level":"info","ts":1688662440.8014708,"logger":"websocket.session","msg":"disconnected","id":"344660355856748546"}
{"level":"info","ts":1688662440.8016398,"logger":"http.rest","msg":"HTTP response GET /api/websocket","requestID":"9478ee686179/Nc6uRhlTCI-007782","method":"GET","path":"/api/websocket","status":0,"size":0,"duration":60.005684145}
{"level":"info","ts":1688662444.7830906,"logger":"http.rest","msg":"HTTP request GET /api/websocket","requestID":"9478ee686179/Nc6uRhlTCI-007793","method":"GET","path":"/api/websocket","size":0,"remote":"REMOTE_CENSORED"}
{"level":"debug","ts":1688662444.8212895,"logger":"websocket.session","msg":"authenticated","id":"344660463214153730","userID":"304789834122149892","roles":[]}
{"level":"info","ts":1688662445.3925595,"logger":"http.rest","msg":"HTTP request GET /favicon.ico","requestID":"9478ee686179/Nc6uRhlTCI-007794","method":"GET","path":"/favicon.ico","size":0,"remote":"REMOTE_CENSORED"}
{"level":"info","ts":1688662445.392653,"logger":"http.rest","msg":"HTTP response GET /favicon.ico","requestID":"9478ee686179/Nc6uRhlTCI-007794","method":"GET","path":"/favicon.ico","status":200,"size":1252,"duration":3.623e-05}
{"level":"info","ts":1688662449.0218868,"logger":"http.rest","msg":"HTTP request GET /api/compose/namespace/304789571474829316/module/312906757590482948/record/","requestID":"9478ee686179/Nc6uRhlTCI-007795","method":"GET","path":"/api/compose/namespace/304789571474829316/module/312906757590482948/record/","size":0,"remote":"REMOTE_CENSORED"}
{"level":"info","ts":1688662449.102075,"logger":"http.rest","msg":"HTTP response GET /api/compose/namespace/304789571474829316/module/312906757590482948/record/","requestID":"9478ee686179/Nc6uRhlTCI-007795","method":"GET","path":"/api/compose/namespace/304789571474829316/module/312906757590482948/record/","status":200,"size":86144,"duration":0.080130574}
{"level":"error","ts":1688662450.741312,"logger":"websocket.session","msg":"read failure","id":"344660372533301250","error":"websocket read failed: websocket: close 1006 (abnormal closure): unexpected EOF"}
{"level":"info","ts":1688662450.7413778,"logger":"websocket.session","msg":"disconnected","id":"344660372533301250"}
{"level":"info","ts":1688662450.7415104,"logger":"http.rest","msg":"HTTP response GET /api/websocket","requestID":"9478ee686179/Nc6uRhlTCI-007785","method":"GET","path":"/api/websocket","status":0,"size":0,"duration":60.001862705}
{"level":"error","ts":1688662453.7954924,"logger":"websocket.session","msg":"read failure","id":"344660377667129346","error":"websocket read failed: websocket: close 1006 (abnormal closure): unexpected EOF"}
{"level":"info","ts":1688662453.795552,"logger":"websocket.session","msg":"disconnected","id":"344660377667129346"}
{"level":"info","ts":1688662453.7957065,"logger":"http.rest","msg":"HTTP response GET /api/websocket","requestID":"9478ee686179/Nc6uRhlTCI-007786","method":"GET","path":"/api/websocket","status":0,"size":0,"duration":60.004218438}
{"level":"info","ts":1688662454.6946497,"logger":"http.rest","msg":"HTTP request GET /api/compose/namespace/304789571474829316/module/312906757590482948/record/","requestID":"9478ee686179/Nc6uRhlTCI-007796","method":"GET","path":"/api/compose/namespace/304789571474829316/module/312906757590482948/record/","size":0,"remote":"REMOTE_CENSORED"}
{"level":"info","ts":1688662454.7082627,"logger":"http.rest","msg":"HTTP response GET /api/compose/namespace/304789571474829316/module/312906757590482948/record/","requestID":"9478ee686179/Nc6uRhlTCI-007796","method":"GET","path":"/api/compose/namespace/304789571474829316/module/312906757590482948/record/","status":200,"size":703,"duration":0.01354417}
{"level":"info","ts":1688662454.731208,"logger":"http.rest","msg":"HTTP request GET /api/websocket","requestID":"9478ee686179/Nc6uRhlTCI-007797","method":"GET","path":"/api/websocket","size":0,"remote":"REMOTE_CENSORED"}
{"level":"debug","ts":1688662454.7552013,"logger":"websocket.session","msg":"authenticated","id":"344660479907483650","userID":"336419858830893061","roles":[]}
{"level":"info","ts":1688662457.783,"logger":"http.rest","msg":"HTTP request GET /api/websocket","requestID":"9478ee686179/Nc6uRhlTCI-007798","method":"GET","path":"/api/websocket","size":0,"remote":"REMOTE_CENSORED"}
{"level":"debug","ts":1688662457.818548,"logger":"websocket.session","msg":"authenticated","id":"344660485024534530","userID":"334217880621051906","roles":[]}

I count 18 instances in the last 100 log lines where request durations are at 1 minutes. What's happening here?
Our current workaround is to restart docker compose which has been happening multiple times every day.
Expected Behavior
No response
Steps To Reproduce
No response
Environment and versions
No response
Anything else?
No response

This is a regression of
https://forum.cortezaproject.org/t/record-view-is-very-slow-in-medium-size-module/1427/2
@petergrlica , you mentioned in our email that you would create an issue for this. Did you ever manage to?


Setup a self-hosted docs.rs for private crate registry

I'm trying to host the docs of some private crates.
I've found https://forge.rust-lang.org/docs-rs/self-hosting.html but it does not say anything about private registry.
Also according to https://github.com/rust-lang/docs.rs/issues/1791 it was outdated a year ago?
Is there an up-to-date doc for this matter?

Sadly, there is no up-to-date doc. Feel free to ask any question in zulip, we'll try to help.
The repository for the documentation above is https://github.com/rust-lang/rust-forge/, so

but it does not say anything about private registry

The registry index can be configured using REGISTRY_URL (for the index git repository) and DOCSRS_REGISTRY_API_HOST (for the API endpoint).


Emit marked source for function parameters

Luckily this is also a trivial extension of the marked source we already
emit for other variables.

@kythe please take a look

@schroederc @zrlk shahms mentioned you two are the most familiar with marked source on another PR, do you mind looking at this one too?

@kythe could this be reviewed?

Ping? Is this still relevant?

Yes but I am no longer at Google, cannot meaningfully contribute. Closing.


[WIP] Create some testing scripts - for e2e

Create some scripts in contrib/bin to:

run helm from a container
run kubectl from a container
start hyperkube in docker
create the helm and kubectl images used by above
execute the "walkthru" example via a script

Added it to the e2e testing even though its not 100% complete yet.
The controller doesn't start yet.
To test it try: make test-e2e.
I put stuff under contrib/bin  since I wasn't sure where to push utility type of scripts.
Signed-off-by: Doug Davis<EMAIL_ADDRESS>

even though the controller isn't starting properly, which I think is a just a config issue, I opening this up for review.
@bmelville do you happen to know if the controller requires any special flags/options?

@duglin this is expected to run in Jenkins, right?  We will not be able to run a kubernetes cluster in travis, I'm afraid.

@pmorie what's the issue? Need privileged containers?

Yep, capabilities are the issue. For clarity, the kubelet is the long pole.
For example, you need cap_mount to use secret volumes, and travis won't let
you have it.
I'm actually wondering if we could get away with it for now, we won't be
able to long term but it would be interesting to see if we could at this
moment.
One other issue with travis is bandwidth. At the free tier you get two
executors in travis, which is not a lot.  I've found in the past on k8s and
other projects that it's best to leverage travis for fast and 'light'
workloads and run your heavier stuff on a jenkins you can give some real
resources to. Note, i am assuming that we only have access to the free tier
and do not inherit any special paid tier by virtue of being in kubernetes
incubator.
On Mon, Jan 16, 2017 at 6:52 PM Doug Davis<EMAIL_ADDRESS>wrote:

@pmorie https://github.com/pmorie what's the issue? Need privileged
containers?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/kubernetes-incubator/service-catalog/pull/237#issuecomment-272987751,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAWXmMVD0DfcqMHSZ--ci5bjI3yBSGWhks5rTAKrgaJpZM4Le_ub
.

@duglin what's the status of this PR?

@arschles I'd like to finish it out, but I'm in the middle of marathon travels - if it sitting in the list is annoying let me know and I'll close it and reopen when its ready

@duglin I'm pretty sure that we now have the equivalent of this in the jenkins setup.  Is there a reason to keep this open?

ok - and if not I can reopen a new one.


port: [#6793][#6792] Composer Bot with QnA Intent recognized triggers duplicate QnA queries

#minor
Description
This PR ports the PR # 6793 which fixes the double QnA trace issue.
Specific Changes

Updated AdaptiveDialog to avoid reprocessing recognized activities by adding a condition if the recognized event was already processed.
Added unit tests to validate the new condition works.

Testing
The following image shows how it just throws one trace by every message.

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Details

10 of 10 (100.0%)  changed or added relevant lines in 2 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage decreased (-0.4%) to 84.078%

Totals

Change from base Build<PHONE_NUMBER>:
-0.4%

Covered Lines:
20347

Relevant Lines:
22904

💛  - Coveralls

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Details

10 of 10 (100.0%)  changed or added relevant lines in 2 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.002%) to 84.433%

Totals

Change from base Build<PHONE_NUMBER>:
0.002%

Covered Lines:
20429

Relevant Lines:
22904

💛  - Coveralls

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Details

10 of 10 (100.0%)  changed or added relevant lines in 2 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage decreased (-0.4%) to 84.078%

Totals

Change from base Build<PHONE_NUMBER>:
-0.4%

Covered Lines:
20347

Relevant Lines:
22904

💛  - Coveralls

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Details

10 of 10 (100.0%)  changed or added relevant lines in 2 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.002%) to 84.433%

Totals

Change from base Build<PHONE_NUMBER>:
0.002%

Covered Lines:
20429

Relevant Lines:
22904

💛  - Coveralls

Promoted /4700


RM-18 fix docs build

docs/source/requirements.txt:20: # TODO: try to replace this file in favor of ONE requirements.txt
docs/source/requirements.txt:21: # TODO: add a test to validate docs build that can run locally and in CI

Reduce total number of punchlist violations to 0 or below!

Tasks: TOP => quality
(See full trace by running task with --trace)
Existing violations: 0
Found 2 punchlist violations

Exited with code exit status 1

Does this mean I'm not allowed to write TODO?

Gonna wait to merge this until after https://github.com/bluelabsio/records-mover/pull/193 since the airflow version change will affect this

#193 now merged @Brunope!

@Brunope:

Does this mean I'm not allowed to write TODO?

That's just the default setting of a goofy tool called punchlist I had configured here.  I generally use those as things I want to finish out before I complete a PR, with the idea that any longer term things I remember to put those into a tracker somewhere else with the rest of the backlog.
If you wanted to change that policy, you could add 'punchlist' to the array here and disable it: https://github.com/bluelabsio/records-mover/blob/master/Rakefile.quality#L21-L31

copied context from my last commit message because github doesn't show those by default
By upgrading the airflow version, pip was unable to be a real dependency
manager and figure out what dependencies it needed to install ???
I tried to give it some hints about what versions of some other
packages it needed, but it didn't help. So I clobbered the whole thing
with the result of pip freeze and made a few manual changes necessary
to get things to build.

Take another look at the changes if you want @ryantimjohn , I'll plan to merge this tomorrow


Handle multiple study codes

some students have multiple study codes. this adds an additional select form where the user has to select the current study code, before he can register at the page.

I got the confirmation that this is working now.


⚠ Bofrost.at has degraded performance

In d42bd72, Bofrost.at (https://www.bofrost.at) experienced degraded performance:

HTTP code: 200
Response time: 927 ms

Resolved: Bofrost.at performance has improved in 1224553 after 14 minutes.


How to install the v1.0.0 version?

I encouter the same issue as #114 .
Following the suggestion, I try to upgrade ffcv to v1.0.0 version.
As it's has not been released.
I try to install it by pip from the github branch.
I install the reqirements following the instruction
conda create -y -n ffcv python=3.9 cupy pkg-config compilers libjpeg-turbo opencv pytorch torchvision cudatoolkit=11.3 numba -c pytorch -c conda-forge
conda activate ffcv

and then
pip install<EMAIL_ADDRESS>
But I meet the following Error.
Requirement already satisfied: fastargs in ./miniconda3/envs/ffcv/lib/python3.9/site-packages (from ffcv==0.0.3rc1) (1.2.0)
ERROR: Could not find a version that satisfies the requirement cv2 (from ffcv) (from versions: none)
ERROR: No matching distribution found for cv2

Sorry that I didn't solve it, even I haved tried several solutions from google.
I works on Arch system with miniconda3.
Would you please give me some instructions how to install the V1.0.0 version?
Thanks for your time.

I removed cv2 from the install_requires in the setup.py, and then installed successfully.


Where does the wget data download come from? How is it generated?

This info should be in the README and explain where it comes from.
Is it possible to scrape this data myself instead of downloading it from your github site?

Do you mean the cache? It is built by GH Actions and served via GH pages. Or what do you mean?

Thanks! Just added a comment to the README with this explanation, in case it's not obvious to anyone else. Seems like an important thing to note in the "Development" section, in case anyone else isn't too familiar with how GitHub Pages/Actions work


Reported properties are getting client-side when reading the direct method

Hi,
Reported properties are getting client-side when reading the direct method.
I wrote the following portion of code to read the direct method on client side
uint32_t ulHandleCommand( AzureIoTHubClientCommandRequest_t * pxMessage,
                          uint32_t * pulResponseStatus,
                          uint8_t * pucCommandResponsePayloadBuffer,
                          uint32_t ulCommandResponsePayloadBufferSize )
{
     AzureIoTResult_t xResult;
    AzureIoTJSONReader_t xReader;
    AzureIoTJSONWriter_t xWriter;
    int32_t lCommandNameLength;
    int32_t ulCommandResponsePayloadLength;
    LogInfo( ( "Command payload : %.*s \r\n",
               pxMessage->ulPayloadLength,
               ( const char * ) pxMessage->pvMessagePayload ) );
   ESP_LOGI("AZ IOT","Name > %s\r\n",
                   pxMessage->pucCommandName);

I closed relay 5 in the direct method and then get the command and reported properties on the client side. What is the reason behind this?
I (438071) MQTT: Packet received. ReceivedBytes=45.
I (438071) MQTT: De-serialized incoming PUBLISH packet: DeserializerResult=MQTTSuccess.
I (438071) MQTT: State record updated. New state=MQTTPublishDone.
I (438081) AZ IOT: $iothub/methods/POST/RLY5-Close/?$rid=1
I (438081) AzureIoT: prvHandleCommand called for DirectMethod
I (438101) AzureIoT: Command payload : null
I (438101) AZ IOT: Name > RLY5-Close/?$rid=1null$rid=3":1},"reported":{"GPS":{"Lat":"0.00000000","Long":"0.00000000"},"FirmwareDetails":{"Version":"1.2","BuildDate":"2022-04-10T06:04:00Z"},"$version":21689}}vices%2FED-02&sig=wsIpKocAATyM6Wvyoj6CS914Wjh8VwhFgAuEhz%2FMM3A%3D&se=1669808360

I'm not familiar with the way you're doing things here. The way I do it in our project is, after successful AzureIoTHubClient_Connect(), execute AzureIoTHubClient_SubscribeCommand() to add a callback method. Within that callback method, you process the incoming message, then respond to the command call with AzureIoTHubClient_SendCommandResponse()
Bare minimum example:
void connect()
{
    AzureIoTResult_t xResult = AzureIoTHubClient_Connect(&xAzureIoTHubClient, true, &xSessionPresent, CONNACK_RECV_TIMEOUT_MS);
    xResult = AzureIoTHubClient_SubscribeProperties(&xAzureIoTHubClient, propertiesCallback, &xAzureIoTHubClient, SUBSCRIBE_TIMEOUT);
}

Callback:
void commandCallback(AzureIoTHubClientCommandRequest_t *pxMessage, void *pvContext)
{
    //process pxMessage

    //respond
    AzureIoTResult_t xResult = AzureIoTHubClient_SendCommandResponse(xHandle, pxMessage, result, (const uint8_t *)deviceMethodResponse, strlen(deviceMethodResponse));
}

Thanks for helping out here @rtheil-growlink
Hey @Noushadalik
I think the issue is that you're doing a %s format on a value that isn't guaranteed to be NULL terminated. Below are the fields in the struct, one of which is a command name length:
https://github.com/Azure/azure-iot-middleware-freertos/blob/54fa7819c5e3ca76dc4c6b0f9ef0d233ed5b273a/source/include/azure_iot_hub_client.h#L128-L129
If you previously received a device twin in the same buffer or a buffer that is placed near the one which has the topic, you will have a buffer overrun issue.
You could try something like the following to get only the characters for the command name:
ESP_LOGI("AZ IOT","Name > %.*s\r\n",
                   pxMessage->usCommandNameLength, pxMessage->pucCommandName);

Note the .* placed before the s which allows you to pass a length.

Closing this issue for now due to inactivity. If you would like it reopened, please let us know. For any other questions, please open another Github issue.


[fuzz] remove tcp proxy from network fuzzers

Signed-off-by: Asra Ali<EMAIL_ADDRESS>Commit Message: Remove tcp-proxy from network fuzzer because the upstream connection isn't set up and we fail on this ASSERT:
https://github.com/envoyproxy/envoy/blob/280654be74c4760a7f61f3658b035e4800f2deca/source/common/tcp_proxy/tcp_proxy.cc#L558
Risk Level: Low

Do we need some further ASSERTs in the TCP proxy filter like possibly: ASSERT(upstream_ != nullptr);

Do we need some further ASSERTs in the TCP proxy filter like possibly: ASSERT(upstream_ != nullptr);

It is possible the upstream_ was destroyed already, so this is exactly what this ASSERT is capturing. Do you mean for clarity's sake?
https://github.com/envoyproxy/envoy/blob/280654be74c4760a7f61f3658b035e4800f2deca/source/common/tcp_proxy/tcp_proxy.cc#L552-L554

Do we need some further ASSERTs in the TCP proxy filter like possibly: ASSERT(upstream_ != nullptr);

It is possible the upstream_ was destroyed already, but then we should not be reading. This is exactly what this ASSERT is capturing. Do you mean for clarity's sake?
https://github.com/envoyproxy/envoy/blob/280654be74c4760a7f61f3658b035e4800f2deca/source/common/tcp_proxy/tcp_proxy.cc#L552-L554

I wonder if the ASSERT and reset of the idle timer belong in the body of the "if (upstream_)"
I think you get to keep the fuzz test in that case.
Are there plans to improve these fuzz tests by introducing an upstream connection?

Are there plans to improve these fuzz tests by introducing an upstream connection?

Yes, I should have mentioned -- we are having a CNCF contractor make dedicated TcpProxy fuzzers (hence why this one isn't as critical). Keeping the fuzz test with this issue may give a false sense of security, but I guess you still get configuration fuzzing.
Hmmm maybe I don't see something, but I think the ASSERT is useful there to validate that if there should be no reads when there is no upstream.


Failed to run platform ios app with bazel

Describe the bug
I tried to run the test app on the simulator with this command: bazel run //platform/ios:App, but it did not work.
To Reproduce
Steps to reproduce the behavior:

Clone this repo and set up provision profile.
run bazel run //platform/ios:App
Got an issue as below:

INFO: Analyzed target //platform/ios:App (0 packages loaded, 0 targets configured).
/maplibre-native/platform/ios/BUILD.bazel:185:16: Linking platform/ios/App_bin failed: (Exit 1): wrapped_clang failed: error executing ObjcLink command (from target //platform/ios:App) external/apple_support~~apple_cc_configure_extension~local_config_apple_cc/wrapped_clang ... (remaining 1 argument skipped)

Use --sandbox_debug to see verbose messages from the sandbox and retain the sandbox build root for debugging
ld: building for 'iOS-simulator', but linking in dylib<EMAIL_ADDRESS>built for 'macOS'
clang: error: linker command failed with exit code 1 (use -v to see invocation)
Error in child process '/usr/bin/xcrun'. 1
Target //platform/ios:App failed to build
Use --verbose_failures to see the command lines of failed build steps.
INFO: Elapsed time: 0.582s, Critical Path: 0.17s
INFO: 2 processes: 2 internal.
ERROR: Build did NOT complete successfully
ERROR: Build failed. Not running target

Expected behavior
The build should be successful.
Platform information (please complete the following information):

OS: MacOS 14.5
Platform: IOS
Version: 6.5.0

Bazel can only run applications in the simulator, so make sure you have Xcode installed and at least one simulator device enabled.
Also make sure you build for Metal
bazel run //platform/ios:App --//:renderer=metal

It is easier to run with Xcode, as it will install the needed simulator on request. See https://github.com/maplibre/maplibre-native/blob/main/platform/ios/CONTRIBUTING.md#bazel to set up an Xcode project.


DOC-939: Apply changes to 22.1

Fixes DOC-939

This change is

This was already approved in #12971 and just needs to be applied to 22.1.


Directive templateurl is not working with lazyloading module in ui-router.

Hi,
I am using oclayload for load module lazily, and make split chunks using web pack. Some directive depends on lazily load the module when any state invoke, In directive have templatedUrl these are not registered lazily and showing 404 not found file.html.

If you want to load modules lazily, you can do it by removing ngtemplate-loader, and using html-loader directly for processing your html templates. Your templates should then be passed to your directives/states using the template property after a standard import.

Thanks, @jfmoy ,
In that case, HTML files will be rendered from a server, I want to avoid this situation.
https://www.npmjs.com/package/gulp-angular-templatecache, This Gulp plugin is working fine with the Lazy load. But I am not able to use both (Webpack and Gulp template cache plugin). I want a solution like this.


[Eligibility Questionnaire] Add escape hatch to each step of eligibility calculator

@tomgebauer Do we want to do this? I think this is a button on each page to submit the form without finishing the whole questionnaire.

Example of "escape hatch". WDYT?

I like it.  I'm not sure if we'll be able to update the actual number of filtered listings while still on the page, but we can explore that.

Let's just have it say "view listings" for now and in the future if we implement the ability to get the actual number we can incorporate it.


usb/usb_host.h: No such file or directory

Hi!
I have try to test usb host function on new esp32-s2 but the compile failed pointed toward "usb/usb_host.h: No such file or directory"
Where I could find that file?
Thanks

The question is what arduino-esp32 are you using? Its been tested with idf-master branch, but that branch recently has been merged into master, so you have to use master branch. It wont work with any version released in boards manager yet.

I used Arduino ESP-32 version 2.0.0 which support ESP32-S2.
https://github.com/espressif/arduino-esp32

Master:
https://github.com/espressif/arduino-esp32
v2.0.0:
https://github.com/espressif/arduino-esp32/tree/2.0.0
You cant use master if you install with boards manager, you have to install arduino-esp32 manually.  There should be instruction how to do it.


Uncaught Error: Cannot find module 'atom-space-pen-views'

Because my company blocks github access, and the proxy setup involves multiple IPs and user credentials, I have to install project-manger manually by

Download and extract master branch to a temp folder
Run command line in that folder: apm link
Click alt-shirt-p in windows

then I got the error.
It is an indispensable atom plugin to me. I would appreciate if you can fix the issue.

[Enter steps to reproduce below:]

...
...

Atom Version: 1.0.2
System: Microsoft Windows 7 Enterprise
Thrown From: project-manager package, v1.15.11
Stack Trace
Uncaught Error: Cannot find module 'atom-space-pen-views'
At module.js:330

Error: Cannot find module 'atom-space-pen-views'
  at Module._resolveFilename (module.js:328:15)
  at Function.Module._resolveFilename (C:\Users\uidu7867\AppData\Local\atom\app-1.0.2\resources\app.asar\src\module-cache.js:383:52)
  at Function.Module._load (module.js:270:25)
  at Module.require (module.js:357:17)
  at require (module.js:376:17)
  at Object.<anonymous> (d:\myfiles_ibs\tools\atom\packages\atom-project-manager-master\lib\project-manager-view.coffee:1:33)
  at Object.<anonymous> (d:\myfiles_ibs\tools\atom\packages\atom-project-manager-master\lib\project-manager-view.coffee:1:1)
  at Module._compile (module.js:452:26)
  at Object.requireCoffeeScript (C:\Users\uidu7867\AppData\Local\atom\app-1.0.2\resources\app.asar\node_modules\coffee-cash\lib\coffee-cash.js:85:19)
  at Module.load (module.js:347:32)
  at Function.Module._load (module.js:302:12)
  at Module.require (module.js:357:17)
  at require (module.js:376:17)
  at atom-workspace.subscriptions.add.atom.commands.add.project-manager:toggle (d:\myfiles_ibs\tools\atom\packages\atom-project-manager-master\lib\project-manager.coffee:62:29)
  at CommandRegistry.module.exports.CommandRegistry.handleCommandEvent (C:\Users\uidu7867\AppData\Local\atom\app-1.0.2\resources\app.asar\src\command-registry.js:241:29)
  at C:\Users\uidu7867\AppData\Local\atom\app-1.0.2\resources\app.asar\src\command-registry.js:3:61
  at KeymapManager.module.exports.KeymapManager.dispatchCommandEvent (C:\Users\uidu7867\AppData\Local\atom\app-1.0.2\resources\app.asar\node_modules\atom-keymap\lib\keymap-manager.js:520:16)
  at KeymapManager.module.exports.KeymapManager.handleKeyboardEvent (C:\Users\uidu7867\AppData\Local\atom\app-1.0.2\resources\app.asar\node_modules\atom-keymap\lib\keymap-manager.js:355:22)
  at HTMLDocument.module.exports.WindowEventHandler.onKeydown (C:\Users\uidu7867\AppData\Local\atom\app-1.0.2\resources\app.asar\src\window-event-handler.js:177:20)

Commands
  2x -2:20.6.0 project-manager:toggle (atom-text-editor.editor.is-focused)

Config
{
  "core": {
    "ignoredNames": [
      "obj",
      "src",
      "tstmp",
      ".bak"
    ]
  }
}

Installed Packages
# User
project-manager, v1.15.11

# Dev
No dev packages

You still have to install all dependencies. Running apm install in the folder should solve it :)

Thank you for the reply.
I got another error doing apm install:
d:\tools\atom\packages\atom-project-manager-master>apm install
gyp info it worked if it ends with ok
gyp info using<EMAIL_ADDRESS>gyp info using<EMAIL_ADDRESS>| win32 | ia32
gyp http GET https://atom.io/download/atom-shell/v0.22.0/node-v0.22.0.tar.gz
gyp
d:\tools\atom\packages\atom-project-manager-master>
---------------------------------\
I spent some time trying to figure out. I got my proxy configured and found the issue might be related to apm. The proxy setting seems be broken:
https://github.com/atom/apm/issues/322


Upgrade Docsearch packages to 3.6.0

Description

Updates the Docsearch packages in @astrojs/starlight-docsearch to latest
Adds a newly added label to the Docsearch translations schema

size-limit report 📦

Path
Size

/index.html
5.79 KB (0%)

/_astro/*.js
21.95 KB (0%)

/_astro/*.css
13.62 KB (0%)

Lunaria Status Overview
🌕 This pull request will trigger status changes.

Learn more
By default, every PR changing files present in the Lunaria configuration's files property will be considered and trigger status changes accordingly.
You can change this by adding one of the keywords present in the ignoreKeywords property in your Lunaria configuration file in the PR's title (ignoring all files) or by including a tracker directive in the merged commit's description.

Tracked Files

Locale
File
Note

en
guides/site-search.mdx
Source changed, localizations will be marked as outdated.

Warnings reference

Icon
Description

🔄
The source for this localization has been updated since the creation of this pull request, make sure all changes in the source have been applied.


Fix crashes caused due to missing type specifier on visual shader editor

Fixes #75790
This PR adds (appears to be) a missing vector type specifier for Vector2 variant of Ceil function registered in visual shader editor.
Cause
Creating a Ceil/Vector2 node on visual shader editor crashes the engine, due to the out of bounds error.
this is caused by the fact that the p_ops for AddOption struct corresponding to Ceil/Vector2 has only 1 item in it, instead of 2 items (both function specifier and vector type specifier) like the engine expects.
upon node setup, it tries to access the non-existent 2nd item to figure out which vector type this node should handle, which causes out of bounds.

Thanks! And congrats with your first contribution to the Godot Engine!

Cherry-picked for 4.0.3.


Changed serializable enums to use snake_case

Objective
Fixes #3074
Solution
It was less work than I thought, there were only 5 files with serializable enums. The other serializable types were tuples, so snake_case would be pointless to add to them. I just added serde(rename_all = "snake_case") to the #[cfg_attr] on these enums.

In the issue, you were asking for kebab-case in your examples, however here you have implemented snake_case.
Fwiw I definitely prefer snake case; I think I prefer even PascalCase over kebab-case.

Oops, I meant to have changed it to snake_case before that, I'll fix it. Yeah, I realized that kebab-case wasn't very Rust-like (despite so many crates erroneously using it in their names).

Feedback on #3074 shows that people prefer PascalCase over snake_case. Guess I'm just the minority.


Cache downloaded files

If a user tries to install the same version of Symfony several times, the file should be downloaded only once and saved in, for example, ~/.symfony/cache.
In case the installer provides a cache system, it should be added a new command to clean the cache.

Is this issue solved?

The downloaded file is not cached, but the temp files are removed "most of the times" (with some fatal errors we cannot remove them).

Closing as "won't fix" because now that Symfony Flex replaces the Symfony Installer, we won't add new features to the installer. Thanks for understanding it.


comply with libphonenumber's mainCountryForCode attribute when formatting numbers

see:
https://github.com/google/libphonenumber/blob/55716be400990f6542112323134cc1abc58abc2e/making-metadata-changes.md?plain=1#L34
Fixes: #74

@cedvdb let me know what you think

great !

Sorry for the delay, I added a small comment.


fix: properly fix config flow

Codecov Report

Merging #43 (42d300b) into dev (f3c4612) will increase coverage by 0.58%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##              dev      #43      +/-   ##
==========================================
+ Coverage   92.64%   93.22%   +0.58%
==========================================
  Files           5        5
  Lines         367      369       +2
==========================================
+ Hits          340      344       +4
+ Misses         27       25       -2

Impacted Files
Coverage Δ

custom_components/openei/config_flow.py
94.82% <100.00%> (+1.22%)
:arrow_up:


Introduce Version Catalog, initially intentionally only for Glide

see #2302
My expectation is that if this passes CI and gets merged, Dependabot will automagically propose a bump for Glide - let's try and see.
If this works, we should then migrate to this model. Perhaps that's something that could be "crowd sourced" and fanned out, instead of me doing all migrations myself?
PS: There would be an intermediate phase with "mixed" dependency declaration; to me such a "gradual adoption" is a "feature not a bug", with testing each change, and more sensible than a single big bang all in one migration.

This is actually VERY nice!! I never knew about this:
https://docs.gradle.org/current/userguide/platforms.html
Superb job!

Superb job!

🙇🏽  but credit where credit is due - I learnt about this after doing research starting from this comment!

https://docs.gradle.org/current/userguide/platforms.html

see #2302, also https://developer.android.com/build/migrate-to-catalogs, and https://docs.github.com/en/code-security/dependabot/dependabot-version-updates/about-dependabot-version-updates#gradle for why "My expectation is that if this passes CI and gets merged, Dependabot will automagically propose a bump for Glide - let's try and see."

this is lovely. thanks @vorburger!

If this works, we should then migrate to this model. Perhaps that's something that could be "crowd sourced" and fanned out, instead of me doing all migrations myself? -> agreed.


Changes to visualize clarity-js ^0.2.0

import * as React from "react";

we should update package.json to reference the newer version of clarity-js rather than 0.1.17

Refers to: src/extension/app.tsx:1 in 9945433. [](commit_id =<PHONE_NUMBER>447cbaa3237337f651f50f3fcd7251, deletion_comment = False)

import * as React from "react";

This is merging into clarity020 branch, which is already referencing clarity-js 0.2.0

In reply to: 337020819 [](ancestors = 337020819)

Refers to: src/extension/app.tsx:1 in 9945433. [](commit_id =<PHONE_NUMBER>447cbaa3237337f651f50f3fcd7251, deletion_comment = False)


proxy only not work

Connected but speed is zero.

In this case, a socks proxy is created
And when you use a proxy, this traffic will change

Not traffic, speed is zero and cannot open google


Class name change to ServiceWorkerGlobalScopeMock?

The service-worker-mock class ServiceWorkerGlobalScope, implements the ServiceWorkerGlobalScope interface, but adds a few new properties and methods like trigger().
https://github.com/pinterest/service-workers/blob/1940ec4c2ad360ab0abfc4e133e10355bf584e58/packages/service-worker-mock/index.js#L43
Can it be changed to ServiceWorkerGlobalScopeMock? Yes, A breaking change request. I'm working on writing a TypeScript declaration file for this project, but ServiceWorkerGlobalScope is already use by the interface and class in the TypeScript libraries. Partial example of what could exist: @types/service-worker-mock/index.d.ts
declare module 'service-worker-mock' {
  interface IEnvOptions {
    [key: string]: string;
  }

  interface IListeners {
    [key: string]: (<K extends keyof ServiceWorkerGlobalScopeEventMap>(this: ServiceWorkerGlobalScope, ev: K) => any);
  }

  function makeServiceWorkerEnv(envOptions?: IEnvOptions): ServiceWorkerGlobalScopeMock;
  export default makeServiceWorkerEnv;

  export class ServiceWorkerGlobalScopeMock extends ServiceWorkerGlobalScope {
    public listeners: IListeners;
    constructor(envOptions?: IEnvOptions);

    public trigger(name: string, args: Request): Promise<Response>;
    public trigger(name: string, args: any): Promise<void>;
  }
}

The workaround is global augmentation, but that's not ideal for a number of reasons. Example global.ts:
declare global {
  interface ServiceWorkerListener {
    [key: string]: (<K extends keyof ServiceWorkerGlobalScopeEventMap>(this: ServiceWorkerGlobalScope, ev: K) => any);
  }
  interface ServiceWorkerGlobalScope {
    listeners: ServiceWorkerListener;

    trigger(name: string, args: Request): Promise<Response>;
    trigger(name: string, args: any): Promise<void>;
  }
}

Or perhaps someone has another better workaround?

I've finally been able to publish the project. Super basic types for this project are added in https://github.com/udacity/cloudflare-typescript-workers/blob/master/packages/%40udacity/types-service-worker-mock/src/global.ts Not in the global NPM namespace because it is totally incomplete. This works, it's just non-ideal.
I'm closing the issue for now. Please consider a Class name change in the next major version.


Broken link to Python Hands-On lab

The link to the python lab Build a Modern Application on the Getting Started Resource Center redirects to the Getting Started homepage.
Broken link: https://aws.amazon.com/getting-started/projects/build-modern-app-fargate-lambda-dynamodb-python/
Lab: https://aws.amazon.com/getting-started/hands-on/?getting-started-all.sort-by=item.additionalFields.sortOrder&getting-started-all.sort-order=asc&awsf.getting-started-category=category%23containers&awsf.getting-started-level=*all&awsf.getting-started-content-type=content-type%23hands-on&getting-started-all.q=build%2Bmodern%2Bapplication&getting-started-all.q_operator=AND
The lab is still present in this repo so it seems there was an update or something that broke the link between the docs:
https://github.com/aws-samples/aws-modern-application-workshop/tree/python

Hi,
The link to the python lab Build a Modern Application on the Getting Started Resource Center redirects to the Getting Started homepage.
Broken link: https://aws.amazon.com/getting-started/projects/build-modern-app-fargate-lambda-dynamodb-python/
In the lab the yaml file with the creation of the infrastructure is not found.
Can you help us so that the laboratory is available again from the web?


Add event queue function to space-api-js

we have to do the above for space-api-go

This should come directly on the API object, right?
I have two alternative APIs for this in my mind.
First alternative:
const res = await api.queueEvent("event-type", {"foo": "bar"})
    .delay(0)
    .timestamp(new Date().getTime())
    .options({})
    .apply()

The .apply() method makes it consistent with the rest of the db functions. However, the apply method might give false indication that the event is triggered immediately.
Second alternative:
const res = await api.event("event-type", {"foo": "bar"})
   .delay(0)
   .timestamp(new Date().getTime())
   .options({})
   .queue()

@Jayesh333 close this if its done

Done.


[Improvement][dolphinscheduler-api] Add type definition of global parameter

Search before asking

[X] I had searched in the issues and found no similar feature requirement.

Description
The default type of global parameter is VARCHAR, which may cause error when using it in SQL task (#12837).
DS should support to define the type of global parameters, like local parameter.
Are you willing to submit a PR?

[X] Yes I am willing to submit a PR!

Code of Conduct

[X] I agree to follow this project's Code of Conduct

If there are other reasons for setting the fixed VARCHAR type, just comment and let me know!


Local Environment Setup Keeps Erroring Out

I keep getting a ton of errors after typing "npm install"
I am running the latest npm 9.3 and just installed the latest visual studio c++
I tried running it in cmd, powershell and vs developer cmd
error log attached along with screenshots of the errors
2022-11-22T06_01_29_988Z-debug-0.log

Try node 16.x


Update bank account form schema

Update bank account form schema
This PR updates the schema for the bank account step in payment-provisioning.

account_owner field is no longer limited to just alphabetical characters. Users can now provide numbers and special characters: ,, ., &, -

Links
Closes #767
Developer QA steps
To QA this PR you will need to render the payment-provisioning component and proceed to the bank account form step (step 6). We are testing the account_owner field only.

[ ] Verify that field is no longer limited to letters only. This field should successfully accept strings with numbers, or the special characters: ,, ., &, -

[ ] example string to test: Affordable Dentures & Implants - Birmingham-Hoover, P.C. 546584

Oh yes, good idea!

I asked ChatGPT what would be the typically disallowed characters for this case and it answered this:

I tried entering some special characters, and the field accepted them. Do you think we should consider updating the regex to explicitly disallow those characters?

I asked ChatGPT what would be the typically disallowed characters for this case and it answered this:

I tried entering some special characters, and the field accepted them. Do you think we should consider updating the regex to explicitly disallow those characters?

@TiagoFuelber good thinking to ask chat gpt! I tried testing out the current changes in this PR with all the special characters you listed here - none of them were actually accepted, except for the ones that we have cased/allowed in businessNameRegex from schema-helpers.ts.
Are you sure you were able to pass the validation with any of these special characters? I cannot recreate this on my end. Are you sure you were testing with the Account Owner Name field in the bank_account form step? 🤔
That said - I am totally cool with omitting ', and " from allowed characters. I don't think that would mess anything up since we are stringifying the payload before sending to the BE, however I would rather err on the side of caution here...
@Claudia108 Based on Tiago's comment I am going to remove ' from our regex for this field.

Hey,  yes, I'm running the branch locally and could type those characters here

That's weird.


Update snakeyaml to 2.3

About this PR
📦 Updates org.yaml:snakeyaml from 2.2 to 2.3
Usage
✅ Please merge!
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

🔍 Files still referring to the old version number
The following files still refer to the old version number (2.2).
You might want to review and update them manually.
CHANGELOG.md
docs/images/module-dependencies.svg
docs/images/web-shop-visual-state.svg
docs/images/web-shop-visualization.svg
docs/images/webshop-state-1.svg
docs/images/webshop.svg
http/baker-http-dashboard/package.json
project/Dependencies.scala
project/plugins.sbt

⚙ Adjust future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "org.yaml", artifactId = "snakeyaml" } ]

Or, add this to slow down future updates of this dependency:
dependencyOverrides = [{
  pullRequests = { frequency = "30 days" },
  dependency = { groupId = "org.yaml", artifactId = "snakeyaml" }
}]

labels: library-update, old-version-remains, commit-count:1

:warning: Please install the  to ensure uploads and comments are reliably processed by Codecov.
Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 79.45%. Comparing base (18aa9af) to head (09291b8).

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@           Coverage Diff           @@
##           master    #1742   +/-   ##
=======================================
  Coverage   79.45%   79.45%
=======================================
  Files         144      144
  Lines        5009     5009
  Branches      674      674
=======================================
  Hits         3980     3980
  Misses       1029     1029

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


Start SWS as a service on Windows Server

I'm trying to start Simple Web Server as a service on a Windows Server 2016 by creating a service like this:
New-Service -Name "SimpleWebServer" -DisplayName "Simple Web Server" -Description "Simple Web Server" -StartupType Auto -BinaryPathName "C:\Users<username>\AppData\Local\Programs\simple-web-server\Simple Web Server.exe --service"
The service gets created fine, but when I try to start the service, I get the following error:
The Simple Web Server service failed to start due to the following error:
The service did not respond to the start or control request in a timely fashion.
What am I doing wrong? Or can it not be started as a service?

@ethanaobrien Do you understand this at all?
This is just an Electron thing afaik. If it doesn't work it doesn't work.

I've just solved it by uninstalling and replaced it by an apache server.

I've just solved it by uninstalling and replaced it by an apache server.

@ethanaobrien Do you understand this at all?

I dont, I haven't used windows in months now so I don't have an easy way to test either. This is like an electron thing or the requirement of a gui

The normal and easy way to make an application start as a Service in Windows is to create a Service with Powershell:
New-Service -Name "SimpleWebServer" -DisplayName "Simple Web Server" -Description "Simple Web Server" -StartupType Auto -BinaryPathName "C:\Users<username>\AppData\Local\Programs\simple-web-server\Simple Web Server.exe --service"
After that you only have to start the service - but it returns the error:
"The Simple Web Server service failed to start due to the following error:
The service did not respond to the start or control request in a timely fashion."
I choose another solution in this case by installing Apache for Windows. The only reason for using Windows in this case is that I have a Windows application that runs a diagnostic and security check and generates an HTML report that I want to host internally on a website.

Thanks for explaining that more. I'll close this again since our program probably isn't a good choice for this particular use case, and neither of us know how to fix it. Thanks!