PD Bug: Typeform broke again

Overview
Yup, it needs an update
Current behavior

Console:
renderer.0599ecd76ee17613aad5.js:1 uncaught at hc
 at Aa
 at e
 TypeError: Cannot read property 'type' of undefined
    at https://renderer-assets.typeform.com/renderer.0599ecd76ee17613aad5.js:60:163621
    at u (https://renderer-assets.typeform.com/renderer.0599ecd76ee17613aad5.js:8:44035)
    at Generator._invoke (https://renderer-assets.typeform.com/renderer.0599ecd76ee17613aad5.js:8:43788)
    at Generator.forEach.e.<computed> [as next] (https://renderer-assets.typeform.com/renderer.0599ecd76ee17613aad5.js:8:44392)
    at x (https://renderer-assets.typeform.com/renderer.0599ecd76ee17613aad5.js:60:106295)
    at a (https://renderer-assets.typeform.com/renderer.0599ecd76ee17613aad5.js:60:107161)
    at D (https://renderer-assets.typeform.com/renderer.0599ecd76ee17613aad5.js:60:110209)
    at k (https://renderer-assets.typeform.com/renderer.0599ecd76ee17613aad5.js:60:107681)
    at x (https://renderer-assets.typeform.com/renderer.0599ecd76ee17613aad5.js:60:106355)
    at a (https://renderer-assets.typeform.com/renderer.0599ecd76ee17613aad5.js:60:107161)

Steps to reproduce
Open PD in a new tab, fill out the form, hit submit, and it errors out
Expected behavior
Not that

Seems to have been a Typeform server issue, but we should probably update @typeform/embed just in case that can help


Marathon's Oxygen and Nitrogen miners have incorrect MaxExternalPressure values

Description

The N2/O2 miners on Marathon station are set to a MaxExternalPressure of 300kpa instead of the standard 4500kpa used on all other stations. Over time this leads to a depletion of these gases (due to burn chamber/TEG useage and general spacings).
Reproduction

Spin up Marathon station and check the MaxExternalPressure value on the N2/O2 miner's GasMiner component. You can also remove the gas from the miner's chamber and gas analyze to see it stall out well below 4500kpa.
Screenshots

Additional context

Are you planning on fixing this?

Its a mapping issue and I dont know how to control how those variables are set per-map. The extent of my knowledge is "The code says the MaxExternalPressure is 6500, stations are somehow supposed to have 4500, and Marathon is at 300."


Ability to share gifs to Social Media

This would be an excellent feature to add.  In the meantime does anyone have a good idea how to do this?  I've played around with downloading the gif and sharing via something like: https://pub.dev/packages/appinio_social_share
This results in only the first frame of the gif being uploaded as an image.  So then I thought I guess I need to convert it to an mp4 first.  This is most likely possible but does anyone have a better way?
Thanks!

Hi there.. yea the only reasonable way to share is to do a screen record and then share that file as GIF. The only catch there is currently we dont know whats the loop time for each GIF so running the animation to record just once is a challenge that I see. Would be happy to know if you find some other alternative


Is this project Dead?!? Error when trying to run empire on updated Kali Linux

Empire Version
Master Branch
OS Information (Linux flavor, Python version)
Kali Linux
Expected behavior and description of the error, including any actions taken immediately prior to the error. The more detail the better.
When running ./empire it should run empire, however i get an error (see paste below)
Screenshot of error, embedded text output, or Pastebin link to the error
https://pastebin.com/UDxRbS6i
Traceback (most recent call last):
File "./empire", line 1422, in
main = empire.MainMenu(args=args)
File "/home/god/Desktop/Empire/lib/common/empire.py", line 92, in init
(self.isroot, self.installPath, self.ipWhiteList, self.ipBlackList, self.obfuscate, self.obfuscateCommand) = helpers.get_config('rootuser, install_path,ip_whitelist,ip_blacklist,obfuscate,obfuscate_command')
TypeError: 'NoneType' object is not iterable
Any additional information
I have copied the install.sh new file that was created from 1268 and ran it before installing, however still will not run.
Kali was fully updated before installing, I also tested on fresh download of 2018.4 version before updates and it worked properly.

That error is normally caused by a missing or corrupt database. If data/empire.db exists, back it up, then run setup/reset.sh.

Try pulling from dev, I just merged a PR to fix installs on Kali latest.

what is the process of pulling from a diff branch? Im not familiar with using git that  much. i know git clone and git pull thats about it.
Is this project no longer being maintained/updated anymore?

i got it all working again. Thank you!


4-2b

Compared to CLRS2e's 4-3b, explicitly names the required recurrences and asks for tight bounds instead of upper bounds.


Cursor sometimes jumps when going from tablet to mouse

It doesn't happen all the time, seems to occur more often when the cursor is away from the centre of the screen.
Demonstration: https://drive.google.com/file/d/1f1ZgBxTgwS0Xfhxd5m51YowxT7D8XStP/view?usp=sharing
Kinda hard to show, but the frame statistics bars show the type (mouse: purple, tablet: cyan). Happens a few attempts in, not from the start of the video.

Are you able to reproduce this with high precision mouse turned on?

Can repro with both on and off. Linux.

Just to confirm we're seeing the same thing, can you follow this and confirm the behaviour is the same on linux as on windows?

Framework test TestSceneInputManager
Toggle cursor visibility (so you can see the host cursor position)
Move on tablet
Move on mouse and confirm the ingame cursor always follows the (absolute) position of the host

https://user-images.githubusercontent.com/191335/112810770-59349d00-90b6-11eb-8c88-752948d4d9d3.mp4

Yes, it's the same behaviour. The tablet cursor just needs to affect the host cursor.


Add some editor plugins

Feel free to edit or add more. :)

That's a pretty relevant section to add. Thank you!


[Bug]: Error: failed to sts.GetCallerIdentity when using IRSA

Describe the expected outcome
I am trying to request a certificate from the AWS Private CA. I've configured a subordinate CA to issue client (SSL) certificates. I expect to see an Certificate object in Kubernetes after applying the following:
kind: Certificate
apiVersion: cert-manager.io/v1
metadata:
  name: rsa-cert-2048
  namespace: acm-pca-lab-demo
spec:
  commonName: www.rsa-2048.example.com
  dnsNames:
    - www.rsa-2048.example.com
    - rsa-2048.example.com
  duration: 2160h0m0s
  issuerRef:
    group: awspca.cert-manager.io
    kind: AWSPCAClusterIssuer
    name: demo-test-root-ca
  renewBefore: 360h0m0s
  secretName: rsa-example-cert-2048
  usages:
    - server auth
    - client auth
  privateKey:
    algorithm: "RSA"
    size: 2048

Describe the actual outcome
When I try requesting a certificate, I see the following error in the log:
failed to sts.GetCallerIdentity,"genericissuer":"/demo-test-root-ca","error":"operation error STS: GetCallerIdentity, failed to sign request: failed to retrieve credentials: failed to refresh cached credentials, failed to retrieve credentials, operation error STS: AssumeRoleWithWebIdentity, https response error StatusCode: 403...

I confirmed that my ServiceAccount is referencing the appropriate role ARN and I can see that the IRSA environment variables are being injected into the container for the private CA issuer. I am using public.ecr.aws/k1n1h4h4/cert-manager-aws-privateca-issuer:v1.2.5.
Role trust policy:
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Federated": "arn:aws:iam::<accountID>:oidc-provider/oidc.eks.<region>.amazonaws.com/id/9D5D6851D8B6072929E0E4D984DD9D97"
            },
            "Action": "sts:AssumeRoleWithWebIdentity",
            "Condition": {
                "StringEquals": {
                    "oidc.eks.<region>.amazonaws.com/id/9D5D6851D8B6072929E0E4D984DD9D97:sub": "system:serviceaccount:cert-manager-aws-privateca-issuer:cert-manager",
                    "oidc.eks.<region>.amazonaws.com/id/9D5D6851D8B6072929E0E4D984DD9D97:aud": "sts.amazonaws.com"
                }
            }
        }
    ]
}

Steps to reproduce
Install cert-manager
Install private ca issuer
Configure IRSA and update service account to reference role ARN
Create a AWSPCAClusterIssuer
Create a Certificate
Relevant log output
2023-07-21T21:49:58.654138239Z {"level":"error","ts":"2023-07-21T21:49:58Z","logger":"controllers.GenericIssuer","msg":"failed to sts.GetCallerIdentity","genericissuer":"/demo-test-root-ca","error":"operation error STS: GetCallerIdentity, failed to sign request: failed to retrieve credentials: failed to refresh cached credentials, failed to retrieve credentials, operation error STS: AssumeRoleWithWebIdentity, https response error StatusCode: 403, RequestID: 32db6568-15f5-4045-8b68-e7ce4cfe631d, api error AccessDenied: Not authorized to perform sts:AssumeRoleWithWebIdentity","stacktrace":"github.com/cert-manager/aws-privateca-issuer/pkg/controllers.(*GenericIssuerReconciler).Reconcile\n\t/workspace/pkg/controllers/genericissuer_controller.go:92\ngithub.com/cert-manager/aws-privateca-issuer/pkg/controllers.(*AWSPCAClusterIssuerReconciler).Reconcile\n\t/workspace/pkg/controllers/awspcaclusterissuer_controller.go:57\nsigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).Reconcile\n\t/go/pkg/mod/sigs.k8s.io/controller-runtime@v0.14.6/pkg/internal/controller/controller.go:122\nsigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).reconcileHandler\n\t/go/pkg/mod/sigs.k8s.io/controller-runtime@v0.14.6/pkg/internal/controller/controller.go:323\nsigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).processNextWorkItem\n\t/go/pkg/mod/sigs.k8s.io/controller-runtime@v0.14.6/pkg/internal/controller/controller.go:274\nsigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).Start.func2.2\n\t/go/pkg/mod/sigs.k8s.io/controller-runtime@v0.14.6/pkg/internal/controller/controller.go:235"}
2023-07-21T21:49:58.654179919Z {"level":"error","ts":"2023-07-21T21:49:58Z","msg":"Reconciler error","controller":"awspcaclusterissuer","controllerGroup":"awspca.cert-manager.io","controllerKind":"AWSPCAClusterIssuer","AWSPCAClusterIssuer":{"name":"demo-test-root-ca"},"namespace":"","name":"demo-test-root-ca","reconcileID":"0b844c24-3ce4-4d61-8280-e6be097f70d2","error":"operation error STS: GetCallerIdentity, failed to sign request: failed to retrieve credentials: failed to refresh cached credentials, failed to retrieve credentials, operation error STS: AssumeRoleWithWebIdentity, https response error StatusCode: 403, RequestID: 32db6568-15f5-4045-8b68-e7ce4cfe631d, api error AccessDenied: Not authorized to perform sts:AssumeRoleWithWebIdentity","stacktrace":"sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).reconcileHandler\n\t/go/pkg/mod/sigs.k8s.io/controller-runtime@v0.14.6/pkg/internal/controller/controller.go:329\nsigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).processNextWorkItem\n\t/go/pkg/mod/sigs.k8s.io/controller-runtime@v0.14.6/pkg/internal/controller/controller.go:274\nsigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).Start.func2.2\n\t/go/pkg/mod/sigs.k8s.io/controller-runtime@v0.14.6/pkg/internal/controller/controller.go:235"}
2023-07-21T21:50:09.040586944Z {"level":"error","ts":"2023-07-21T21:50:09Z","logger":"controllers.GenericIssuer","msg":"failed to sts.GetCallerIdentity","genericissuer":"/demo-test-root-ca","error":"operation error STS: GetCallerIdentity, failed to sign request: failed to retrieve credentials: failed to refresh cached credentials, failed to retrieve credentials, operation error STS: AssumeRoleWithWebIdentity, https response error StatusCode: 403, RequestID: 5a05672a-c7bd-4b60-b9d8-828fe934d990, api error AccessDenied: Not authorized to perform sts:AssumeRoleWithWebIdentity","stacktrace":"github.com/cert-manager/aws-privateca-issuer/pkg/controllers.(*GenericIssuerReconciler).Reconcile\n\t/workspace/pkg/controllers/genericissuer_controller.go:92\ngithub.com/cert-manager/aws-privateca-issuer/pkg/controllers.(*AWSPCAClusterIssuerReconciler).Reconcile\n\t/workspace/pkg/controllers/awspcaclusterissuer_controller.go:57\nsigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).Reconcile\n\t/go/pkg/mod/sigs.k8s.io/controller-runtime@v0.14.6/pkg/internal/controller/controller.go:122\nsigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).reconcileHandler\n\t/go/pkg/mod/sigs.k8s.io/controller-runtime@v0.14.6/pkg/internal/controller/controller.go:323\nsigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).processNextWorkItem\n\t/go/pkg/mod/sigs.k8s.io/controller-runtime@v0.14.6/pkg/internal/controller/controller.go:274\nsigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).Start.func2.2\n\t/go/pkg/mod/sigs.k8s.io/controller-runtime@v0.14.6/pkg/internal/controller/controller.go:235"}

### Version

1.2.5

### Have you tried the following?

- [X] Check the [Troubleshooting section](../#troubleshooting)
- [X] Search open [issues](https://github.com/cert-manager/aws-privateca-issuer/issues)

### Category

Authentication Issue

### Severity

Severity 4

Similar to issue #40

Hi Jicowan,
Thanks for reaching out. Let me check on it by reproducing the issue.

There are automated tests with IRSA: https://github.com/cert-manager/aws-privateca-issuer/actions/runs/5596273966/job/15158311416#step:18:1 which passed 3 days ago.
If this turns out to be a reproducible issue, worth taking a look there to see why those tests aren't catching the issue.

Were you using a subordinate CA? I don't know what that would matter, but maybe...

Hi,
On initial look at your role trust policy
"StringEquals": {
                    "oidc.eks.<region>.amazonaws.com/id/9D5D6851D8B6072929E0E4D984DD9D97:sub": "system:serviceaccount:cert-manager-aws-privateca-issuer:cert-manager",
                    "oidc.eks.<region>.amazonaws.com/id/9D5D6851D8B6072929E0E4D984DD9D97:aud": "sts.amazonaws.com"
                }

Doesn't seem to match
"StringEquals": {
	       "${OIDC_URL}:sub": "system:serviceaccount:aws-privateca-issuer:aws-privateca-issuer-sa"
	     }

Could you change it to the latter and see if that helps.

i used eksctl to create the role & service account. You think it's formatting the trust policy incorrectly?

Mind sharing the eksctl commands? Notice they aren't in the reproduction steps.

eksctl create iamserviceaccount \
--cluster=fargate-karpenter \
--namespace=cert-manager \
--name=cert-manager-aws-privateca-issuer \
--attach-policy-arn=arn:aws:iam::<account>:policy/AWSPCAIssuerIAMPolicy \
--override-existing-serviceaccounts \
--region <region> \
--approve

It's failing here, https://github.com/cert-manager/aws-privateca-issuer/blob/65bce2a5a64dbc6be0c32b84a3596fc25385c0c0/pkg/controllers/genericissuer_controller.go#L71-L96, but I'm not sure why. The IRSA env variable are being injected. The AWS SDK should use those to authenticate.

I had the wrong service account name, ugh.

Glad you were able to figure that out.


Microsoft.Build.Evaluation.Project(string projectFile) does not reparse project file the second time a Project instance is constructed

This item was filed by a customer. See below for description & repro steps:
Description: When using the Project(string projectFile) constructor two times after each other, the second time does not read the content from the file, but uses some cache of where it re-uses the content from the first time, even though the file might have changed.
Repro Steps: I have a stand alone solution which has the minimum amount of code to reproduce the issue. It should be self-explanatory.
Impact: Unexpected behaviour, weird issues, lost time. Work around IS available.
See Connect bug here. Please let us know if you want the repro zip.

Hi @Sarabeth-Jaffe-Microsoft, can you send me the repro zip. What means

workaround IS available?
Is this issue still fixed?

Hi, here is the zip-file.
You can see the workaround in the code.
ProjectConstructorBug.zip

Hi @FelixNairz, thanks for the zip. I will see what i can do.

Hi @Sarabeth-Jaffe-Microsoft, can it be that this behavior is wanted. Because in the constructor of ProjectCollection this bool hardcoded. Is that correct?

Ok, i see that it's easier. @FelixNairz, you have to do p.ProjectCollection.UnloadAllProjects()
public void UpgradeProject()
            {
                var p = GetProject();

                try
                {
                    UpgradeRanorexVersion(p);

                    p.Save(this.projectFile);
                }
                finally
                {
                    p.ProjectCollection.UnloadAllProjects();
                    var loadedProjects = ProjectCollection.GlobalProjectCollection.GetLoadedProjects(this.projectFile);
                    Debug.Assert(!loadedProjects.Any());
                }
            }

This forces to unload all projects and cleares the propertyCache.
See here

But there is still the question if user is not completely done and has to do changes on disk, that they are able to read this changes from disk instead of PropertyCache

I still believe this is a bug.
Check the line where I call ProjectCollection.GlobalProjectCollection.UnloadProject(p);
Since, in this example I only load one project anyway, there should be no difference between UnloadProject, and UnloadAllProjects, right? At the time I am done modifying, that project is NOT loaded anymore.
Then I construct the project again inside ProjectUpgrader.UpgradeProject() and it does not look at the file, but at some kind of cache.

Hi @FelixNairz. Yes it unloads the project but it doesn't clear the cache for that project.  Maybe tomorrow I can add some overload's that will load the file from Disk and not from cache. But to be sure @Sarabeth-Jaffe-Microsoft is my statement correct?

I poked through the code and found this comment: https://github.com/Microsoft/msbuild/blob/xplat/src/XMakeBuildEngine/Definition/ProjectCollection.cs#L189-L197
My interpretation of that comment (and of the Project constructor that sets the cache to not reload on disk changes) is that when a build is running, multiple project root elements are opened (transitive imports) and possibly re-opened (via the msbuild task). At the same time as a build is running, other programs may change the xml files for those projects (let's say a property rename that touches all the files that use that property). You don't want your build to capture this inconsistent state (part of the build uses some files with the old property name and part of the build uses files with the new name), and therefore the cache is not flushed, and reloading on disk changes is turned off.
Considering this, I'd vote for just using UnloadAllProjects instead of adding the overload. Adding the overload might lead to some nasty weird bugs down the road, when most projects use the old constructor and a few the new one.

How about a way to remove a particular project from the cache?
In this case at least, I want to ensure this project should be reloaded, but I don't necessary want all other projects to be reloaded too (costly).
Also, the fact that we have two constructors, with

string filename
-XmlReader
as arguments, one using a cached version, and another one not using a cached version is somewhat misleading. I know why this is of course, but it just adds to the confusion.

we want to develop an app which auto migrate lower version projects to higher version.

please help on this

I am not getting any value in match varialble. please suggest any more
var match = this.ranorexSolutionVersionRegex.Match(fileContent);

Team triage: After reading @cdmihai's explanation above about keeping the world view consistent and adding to that the fact that people haven't been asking us for this, we are going to go ahead and close this issue.


can not see devices on map

Hi,
Problem occurs when using ipad or iphone (tested with safari and google chrome browser). When i login to my traccar account then under "Devices" i see all the list of my added devices but i do not see them on the map even if i click on device in list or switch between them.
In earlier times i have seen same issue on windows platform also but that was not so big problem beacause when i clicked on the device then device appeared on the map.

Sounds like you have a problem with WebSocket connection. I suspect it's something with your network.

Ok, do you have some suggestions how to torubleshoot that problem? Lately I installed apache server and generated SSL certificate for https connection, maybe that issue is somehow related with that?

Have you forwarded WebSocket connection in the Apache proxy?

Hi,
Everything is done according to:  "https://www.traccar.org/secure-connection/".
Inside "apache2/sites-available/traccar.conf" i have these lines:

            ServerName IP.IP.IP.IP
            ServerAdmin webmaster@localhost

            DocumentRoot /var/www/html

            ProxyPass /api/socket ws://localhost:8082/api/socket
            ProxyPassReverse /api/socket ws://localhost:8082/api/socket

            ProxyPass / http://localhost:8082/
            ProxyPassReverse / http://localhost:8082/

            SSLEngine on
            SSLCertificateFile /etc/ssl/certs/ssl-cert-snakeoil.pem
            SSLCertificateKeyFile /etc/ssl/private/ssl-cert-snakeoil.key

    </VirtualHost>

Have you enabled all necessary Apache modules?

Yes all modules are enabled,
At the moment i am in situation where everything works with Andorid devices but not working with Apple devices even with different browsers. I see devices on map with Apple devices only when i am in LAN network with server. Problem might be that i have self singned https certificate and maybe that is issue for Apple devices but not for Android.
So i am trying to get normal certificate and then see what is going to happen.

Good info, thank you!


Getting GRPC error after idle for some time

@flyingsilverfin  raising the bug as discussed in stackoverflow.
Description
While trying to create a session to grakn keyspace,after the grakn server is idle for sometime, i am getting session error.
I am using a python 3.6 application which has grakn-client of version 1.6.0 and the grakn server version is 1.6.0. I am getting this error intermittently. Only after the grakn server is idle for some time and on the first try. Trying to connect again after this error, with create the sessionid.
Could not obtain sessionId for keyspace abc
The error generated by python grakn-client is
<_Rendezvous of RPC that terminated with: status = StatusCode.UNAVAILABLE details = “OS Error” debug_error_string = “{“created”:”@1592293927.075671633",“description”:“Error received from peer”,“file”:“src/core/lib/surface/call.cc”,“file_line”:1017,“grpc_message”:“OS Error”,“grpc_status”:14}"
Also we are getting this error while trying to retrive all keyspace name list. client.keyspaces().retrieve() is also throwing this error intermittendly
Environment

OS (where Grakn server runs):  Ubuntu 18.04
Grakn version (and platform):  Grakn Core 1.6.0
Grakn client-python version:  grakn-client 1.6.0
Python version: 3.6
Other environment details: Commonly seen this error in docker env

Reproducible Steps

Try to create a session after idle for long time.

Expected Output
No error
Actual Output
{ <_Rendezvous of RPC that terminated with: status = StatusCode.UNAVAILABLE details = “OS Error” debug_error_string = “{“created”:”@1592293927.075671633",“description”:“Error received from peer”,“file”:“src/core/lib/surface/call.cc”,“file_line”:1017,“grpc_message”:“OS Error”,“grpc_status”:14} }

I wonder if the client drops the gRPC connection if it's inactive for some time.
We should test this at some point.
It may also potentially be resolved in Grakn 2.0.

This scenario should be part of regular usage of Grabl, right, @alexjpwalker @vmax @lolski @lriuui0x0 ? If we don't see it in Grabl means this bug is now resolved in 2.0, right?

Does Grabl open a persisted data session? If it does, then that Session should continually send pulses to the server meaning the gRPC Channel will never be flagged as idle.
If it doesn't always keep a session open, then it's certainly possible that a Channel could become idle, if gRPC enforces some kind of idle timeout (which I believe it does)


Redo transformer categories

Waiting to finalize until we get feedback on google doc

To do:

[x] Individual transformers renames (mean, transform col, etc)
[ ] Reorder transformers + update categories
[ ] Update standalone documentation to be consistent

Should be good to go, barring the controversial "Building" category, which should be easy to change later if need be.

Okay, this seems ready now that that's settled. @stardust66 @P-bibs


Preserve debug console path in the url

When using Debug Console (PowerShell or CMD) and session is timing out, the path is lost and need to navigate all the way back where was working previously. Would be possible to preserve the path?

I think this is basically the same as #1975. Would be great to get a contrib on that :)


@cmdy 大佬，你们已经用到这么大物理机集群了嘛？

嗯嗯 差不多了，我们现在线上单集群已经1700多台物理机了，最近在验证kube-ovn 准备用这套方案

ovn-northd.log
2024-05-24T03:33:30.635Z|283076|northd|ERR|Dropped 28983 log messages in last 72 seconds (most recently, 24 seconds ago) due to excessive rate
2024-05-24T03:33:30.636Z|283077|northd|ERR|lport fake-pod-7b99c6d54d-r87tb.fake-pod in port group node.kwok.node.545 not found.
2024-05-24T03:33:30.762Z|283078|inc_proc_eng|INFO|node: northd, recompute (forced) took 10572ms
2024-05-24T03:33:31.913Z|283079|inc_proc_eng|INFO|node: lflow, recompute (forced) took 860ms
2024-05-24T03:33:32.132Z|283080|jsonrpc|WARN|tcp:[<IP_ADDRESS>]:6642: send error: Broken pipe
2024-05-24T03:33:32.193Z|283081|ovn_northd|INFO|OVNSB commit failed, force recompute next time.
2024-05-24T03:33:32.213Z|283082|timeval|WARN|Unreasonably long 12024ms poll interval (12016ms user, 7ms system)
2024-05-24T03:33:32.213Z|283083|timeval|WARN|faults: 1275 minor, 0 major
2024-05-24T03:33:32.213Z|283084|timeval|WARN|context switches: 0 voluntary, 17 involuntary
2024-05-24T03:33:32.214Z|283085|poll_loop|INFO|wakeup due to [POLLIN][POLLHUP] on fd 3 (/var/run/ovn/ovn-northd.595.ctl<->) at ../lib/stream-fd.c:157 (100% CPU usage)
2024-05-24T03:33:32.215Z|283086|poll_loop|INFO|wakeup due to [POLLIN] on fd 17 (<IP_ADDRESS>:24322<-><IP_ADDRESS>:6641) at ../lib/stream-fd.c:157 (100% CPU usage)
2024-05-24T03:33:32.216Z|283087|reconnect|WARN|tcp:[<IP_ADDRESS>]:6642: connection dropped (Broken pipe)
2024-05-24T03:33:32.216Z|283088|ovn_northd|INFO|ovn-northd lock lost. This ovn-northd instance is now on standby.
2024-05-24T03:33:32.216Z|283089|poll_loop|INFO|wakeup due to 0-ms timeout at tcp:[<IP_ADDRESS>]:6641 (100% CPU usage)
2024-05-24T03:33:32.216Z|283090|reconnect|INFO|tcp:[<IP_ADDRESS>]:6641: connection closed by peer
2024-05-24T03:33:33.217Z|283091|poll_loop|INFO|wakeup due to 1001-ms timeout at ../lib/reconnect.c:677 (100% CPU usage)
2024-05-24T03:33:33.217Z|283092|reconnect|INFO|tcp:[<IP_ADDRESS>]:6641: connecting...
2024-05-24T03:33:33.217Z|283093|reconnect|INFO|tcp:[<IP_ADDRESS>]:6642: connecting...
2024-05-24T03:33:33.217Z|283094|reconnect|INFO|tcp:[<IP_ADDRESS>]:6641: connected
2024-05-24T03:33:33.218Z|283095|reconnect|INFO|tcp:[<IP_ADDRESS>]:6642: connected
2024-05-24T03:33:33.231Z|283096|ovsdb_cs|INFO|tcp:[<IP_ADDRESS>]:6642: clustered database server is not cluster leader; trying another server
2024-05-24T03:33:33.231Z|283097|reconnect|INFO|tcp:[<IP_ADDRESS>]:6642: connection attempt timed out
2024-05-24T03:33:33.231Z|283098|reconnect|INFO|tcp:[<IP_ADDRESS>]:6642: waiting 2 seconds before reconnect
2024-05-24T03:33:33.238Z|283099|ovsdb_cs|INFO|tcp:[<IP_ADDRESS>]:6641: clustered database server is not cluster leader; trying another server
2024-05-24T03:33:33.238Z|283100|reconnect|INFO|tcp:[<IP_ADDRESS>]:6641: connection attempt timed out
2024-05-24T03:33:33.238Z|283101|reconnect|INFO|tcp:[<IP_ADDRESS>]:6641: waiting 2 seconds before reconnect
2024-05-24T03:33:35.233Z|283102|reconnect|INFO|tcp:[<IP_ADDRESS>]:6642: connecting...
2024-05-24T03:33:35.233Z|283103|reconnect|INFO|tcp:[<IP_ADDRESS>]:6642: connected
2024-05-24T03:33:35.236Z|283104|ovn_northd|INFO|ovn-northd lock acquired. This ovn-northd instance is now active.
2024-05-24T03:33:35.236Z|283105|ovsdb_cs|INFO|tcp:[<IP_ADDRESS>]:6642: clustered database server is not cluster leader; trying another server
2024-05-24T03:33:35.236Z|283106|reconnect|INFO|tcp:[<IP_ADDRESS>]:6642: connection attempt timed out
2024-05-24T03:33:35.236Z|283107|reconnect|INFO|tcp:[<IP_ADDRESS>]:6642: waiting 4 seconds before reconnect
2024-05-24T03:33:35.236Z|283108|ovn_northd|INFO|ovn-northd lock lost. This ovn-northd instance is now on standby.
2024-05-24T03:33:35.237Z|283109|reconnect|INFO|tcp:[<IP_ADDRESS>]:6641: connecting...
2024-05-24T03:33:35.237Z|283110|reconnect|INFO|tcp:[<IP_ADDRESS>]:6641: connected
2024-05-24T03:33:35.238Z|283111|ovsdb_cs|INFO|tcp:[<IP_ADDRESS>]:6641: clustered database server is not cluster leader; trying another server
2024-05-24T03:33:35.238Z|283112|reconnect|INFO|tcp:[<IP_ADDRESS>]:6641: connection attempt timed out
2024-05-24T03:33:35.238Z|283113|reconnect|INFO|tcp:[<IP_ADDRESS>]:6641: waiting 4 seconds before reconnect
2024-05-24T03:33:39.237Z|283114|reconnect|INFO|tcp:[<IP_ADDRESS>]:6642: connecting...
2024-05-24T03:33:39.237Z|283115|reconnect|INFO|tcp:[<IP_ADDRESS>]:6642: connected
2024-05-24T03:33:39.237Z|283116|ovn_northd|INFO|ovn-northd lock acquired. This ovn-northd instance is now active.
2024-05-24T03:33:39.239Z|283117|reconnect|INFO|tcp:[<IP_ADDRESS>]:6641: connecting...
2024-05-24T03:33:39.239Z|283118|reconnect|INFO|tcp:[<IP_ADDRESS>]:6641: connected
2024-05-24T03:33:50.111Z|283119|inc_proc_eng|INFO|node: northd, recompute (forced) took 10843ms
2024-05-24T03:33:51.256Z|283120|inc_proc_eng|INFO|node: lflow, recompute (forced) took 860ms
2024-05-24T03:33:51.473Z|283121|jsonrpc|WARN|tcp:[<IP_ADDRESS>]:6642: send error: Broken pipe
2024-05-24T03:33:51.538Z|283122|ovn_northd|INFO|OVNSB commit failed, force recompute next time.
2024-05-24T03:33:51.556Z|283123|timeval|WARN|Unreasonably long 12288ms poll interval (12250ms user, 38ms system)
2024-05-24T03:33:51.556Z|283124|timeval|WARN|faults: 1273 minor, 0 major
2024-05-24T03:33:51.556Z|283125|timeval|WARN|disk: 0 reads, 8 writes
2024-05-24T03:33:51.556Z|283126|timeval|WARN|context switches: 0 voluntary, 24 involuntary
2024-05-24T03:33:51.556Z|283127|coverage|INFO|Dropped 1 log messages in last 20 seconds (most recently, 20 seconds ago) due to excessive rate
2024-05-24T03:33:51.556Z|283128|coverage|INFO|Skipping details of duplicate event coverage for hash=ab6315f5
2024-05-24T03:33:51.556Z|283129|poll_loop|INFO|Dropped 3 log messages in last 19 seconds (most recently, 19 seconds ago) due to excessive rate
2024-05-24T03:33:51.556Z|283130|poll_loop|INFO|wakeup due to [POLLIN][POLLHUP] on fd 3 (/var/run/ovn/ovn-northd.595.ctl<->) at ../lib/stream-fd.c:157 (97% CPU usage)
2024-05-24T03:33:51.556Z|283131|poll_loop|INFO|wakeup due to [POLLIN] on fd 17 (<IP_ADDRESS>:24328<-><IP_ADDRESS>:6641) at ../lib/stream-fd.c:157 (97% CPU usage)
2024-05-24T03:33:51.558Z|283132|reconnect|WARN|tcp:[<IP_ADDRESS>]:6642: connection dropped (Broken pipe)
2024-05-24T03:33:51.558Z|283133|reconnect|INFO|tcp:[<IP_ADDRESS>]:6642: continuing to reconnect in the background but suppressing further logging
2024-05-24T03:33:51.558Z|283134|ovn_northd|INFO|ovn-northd lock lost. This ovn-northd instance is now on standby.
2024-05-24T03:33:51.559Z|283135|poll_loop|INFO|wakeup due to 0-ms timeout at tcp:[<IP_ADDRESS>]:6641 (97% CPU usage)
2024-05-24T03:33:51.559Z|283136|reconnect|INFO|tcp:[<IP_ADDRESS>]:6641: connection closed by peer
2024-05-24T03:33:52.560Z|283137|reconnect|INFO|tcp:[<IP_ADDRESS>]:6641: connecting...
2024-05-24T03:33:52.560Z|283138|reconnect|INFO|tcp:[<IP_ADDRESS>]:6641: connected
2024-05-24T03:33:52.571Z|283139|ovsdb_cs|INFO|tcp:[<IP_ADDRESS>]:6641: clustered database server is not cluster leader; trying another server
2024-05-24T03:33:52.571Z|283140|reconnect|INFO|tcp:[<IP_ADDRESS>]:6641: connection attempt timed out
2024-05-24T03:33:52.571Z|283141|reconnect|INFO|tcp:[<IP_ADDRESS>]:6641: waiting 2 seconds before reconnect
2024-05-24T03:33:54.572Z|283142|reconnect|INFO|tcp:[<IP_ADDRESS>]:6641: connecting...
2024-05-24T03:33:54.572Z|283143|reconnect|INFO|tcp:[<IP_ADDRESS>]:6641: connected
2024-05-24T03:33:54.583Z|283144|ovsdb_cs|INFO|tcp:[<IP_ADDRESS>]:6641: clustered database server is not cluster leader; trying another server
2024-05-24T03:33:54.583Z|283145|reconnect|INFO|tcp:[<IP_ADDRESS>]:6641: connection attempt timed out
2024-05-24T03:33:54.583Z|283146|reconnect|INFO|tcp:[<IP_ADDRESS>]:6641: waiting 4 seconds before reconnect
2024-05-24T03:33:58.584Z|283147|reconnect|INFO|tcp:[<IP_ADDRESS>]:6641: connecting...
2024-05-24T03:33:58.584Z|283148|reconnect|INFO|tcp:[<IP_ADDRESS>]:6641: connected
2024-05-24T03:33:59.559Z|283149|reconnect|INFO|tcp:[<IP_ADDRESS>]:6642: connected
2024-05-24T03:33:59.560Z|283150|ovn_northd|INFO|ovn-northd lock acquired. This ovn-northd instance is now active.
2024-05-24T03:33:59.560Z|283151|ovsdb_cs|INFO|tcp:[<IP_ADDRESS>]:6642: clustered database server is not cluster leader; trying another server
2024-05-24T03:33:59.560Z|283152|ovn_northd|INFO|ovn-northd lock lost. This ovn-northd instance is now on standby.
2024-05-24T03:34:07.564Z|283153|reconnect|INFO|tcp:[<IP_ADDRESS>]:6642: connected
2024-05-24T03:34:07.565Z|283154|ovn_northd|INFO|ovn-northd lock acquired. This ovn-northd instance is now active.
2024-05-24T03:34:07.566Z|283155|ovsdb_cs|INFO|tcp:[<IP_ADDRESS>]:6642: clustered database server is not cluster leader; trying another server
2024-05-24T03:34:07.566Z|283156|ovn_northd|INFO|ovn-northd lock lost. This ovn-northd instance is now on standby.

2024-05-24T03:36:29.427Z|283343|inc_proc_eng|INFO|node: northd, recompute (forced) took 10600ms
2024-05-24T03:36:30.527Z|283344|inc_proc_eng|INFO|node: lflow, recompute (forced) took 808ms
2024-05-24T03:36:30.755Z|283345|jsonrpc|WARN|tcp:[<IP_ADDRESS>]:6642: send error: Broken pipe
2024-05-24T03:36:30.823Z|283346|ovn_northd|INFO|OVNSB commit failed, force recompute next time.
2024-05-24T03:36:30.841Z|283347|timeval|WARN|Unreasonably long 12014ms poll interval (12002ms user, 11ms system)
2024-05-24T03:36:30.841Z|283348|timeval|WARN|faults: 1650 minor, 0 major
2024-05-24T03:36:30.841Z|283349|timeval|WARN|context switches: 0 voluntary, 14 involuntary
2024-05-24T03:36:30.841Z|283350|poll_loop|INFO|wakeup due to [POLLIN] on fd 3 (<IP_ADDRESS>:24380<-><IP_ADDRESS>:6641) at ../lib/stream-fd.c:157 (100% CPU usage)
2024-05-24T03:36:30.842Z|283351|reconnect|WARN|tcp:[<IP_ADDRESS>]:6642: connection dropped (Broken pipe)
2024-05-24T03:36:30.842Z|283352|ovn_northd|INFO|ovn-northd lock lost. This ovn-northd instance is now on standby.
2024-05-24T03:36:30.843Z|283353|poll_loop|INFO|wakeup due to 0-ms timeout at tcp:[<IP_ADDRESS>]:6641 (100% CPU usage)
2024-05-24T03:36:30.843Z|283354|reconnect|INFO|tcp:[<IP_ADDRESS>]:6641: connection closed by peer
2024-05-24T03:36:31.843Z|283355|poll_loop|INFO|wakeup due to 999-ms timeout at ../lib/reconnect.c:677 (100% CPU usage)
2024-05-24T03:36:31.843Z|283356|reconnect|INFO|tcp:[<IP_ADDRESS>]:6641: connecting...
2024-05-24T03:36:31.843Z|283357|reconnect|INFO|tcp:[<IP_ADDRESS>]:6642: connecting...
2024-05-24T03:36:31.843Z|283358|poll_loop|INFO|wakeup due to [POLLOUT] on fd 3 (<IP_ADDRESS>:50246<-><IP_ADDRESS>:6641) at ../lib/stream-fd.c:153 (100% CPU usage)
2024-05-24T03:36:31.843Z|283359|reconnect|INFO|tcp:[<IP_ADDRESS>]:6641: connected
2024-05-24T03:36:31.844Z|283360|reconnect|INFO|tcp:[<IP_ADDRESS>]:6642: connected
2024-05-24T03:36:31.858Z|283361|ovsdb_cs|INFO|tcp:[<IP_ADDRESS>]:6642: clustered database server is not cluster leader; trying another server
2024-05-24T03:36:31.858Z|283362|reconnect|INFO|tcp:[<IP_ADDRESS>]:6642: connection attempt timed out
2024-05-24T03:36:31.858Z|283363|reconnect|INFO|tcp:[<IP_ADDRESS>]:6642: waiting 2 seconds before reconnect
2024-05-24T03:36:31.864Z|283364|ovsdb_cs|INFO|tcp:[<IP_ADDRESS>]:6641: clustered database server is not cluster leader; trying another server
2024-05-24T03:36:31.864Z|283365|reconnect|INFO|tcp:[<IP_ADDRESS>]:6641: connection attempt timed out
2024-05-24T03:36:31.864Z|283366|reconnect|INFO|tcp:[<IP_ADDRESS>]:6641: waiting 2 seconds before reconnect
2024-05-24T03:36:33.859Z|283367|reconnect|INFO|tcp:[<IP_ADDRESS>]:6642: connecting...
2024-05-24T03:36:33.859Z|283368|reconnect|INFO|tcp:[<IP_ADDRESS>]:6642: connected
2024-05-24T03:36:33.860Z|283369|ovn_northd|INFO|ovn-northd lock acquired. This ovn-northd instance is now active.
2024-05-24T03:36:33.860Z|283370|ovsdb_cs|INFO|tcp:[<IP_ADDRESS>]:6642: clustered database server is not cluster leader; trying another server
2024-05-24T03:36:33.860Z|283371|reconnect|INFO|tcp:[<IP_ADDRESS>]:6642: connection attempt timed out
2024-05-24T03:36:33.860Z|283372|reconnect|INFO|tcp:[<IP_ADDRESS>]:6642: waiting 4 seconds before reconnect
2024-05-24T03:36:33.860Z|283373|ovn_northd|INFO|ovn-northd lock lost. This ovn-northd instance is now on standby.
2024-05-24T03:36:33.863Z|283374|reconnect|INFO|tcp:[<IP_ADDRESS>]:6641: connecting...
2024-05-24T03:36:33.863Z|283375|reconnect|INFO|tcp:[<IP_ADDRESS>]:6641: connected
2024-05-24T03:36:33.864Z|283376|ovsdb_cs|INFO|tcp:[<IP_ADDRESS>]:6641: clustered database server is not cluster leader; trying another server
2024-05-24T03:36:33.864Z|283377|reconnect|INFO|tcp:[<IP_ADDRESS>]:6641: connection attempt timed out
2024-05-24T03:36:33.864Z|283378|reconnect|INFO|tcp:[<IP_ADDRESS>]:6641: waiting 4 seconds before reconnect
2024-05-24T03:36:37.861Z|283379|reconnect|INFO|tcp:[<IP_ADDRESS>]:6642: connecting...
2024-05-24T03:36:37.861Z|283380|reconnect|INFO|tcp:[<IP_ADDRESS>]:6642: connected
2024-05-24T03:36:37.863Z|283381|ovn_northd|INFO|ovn-northd lock acquired. This ovn-northd instance is now active.
2024-05-24T03:36:37.864Z|283382|reconnect|INFO|tcp:[<IP_ADDRESS>]:6641: connecting...
2024-05-24T03:36:37.864Z|283383|reconnect|INFO|tcp:[<IP_ADDRESS>]:6641: connected
2024-05-24T03:36:49.551Z|283384|inc_proc_eng|INFO|node: northd, recompute (forced) took 10650ms
2024-05-24T03:36:50.660Z|283385|inc_proc_eng|INFO|node: lflow, recompute (forced) took 820ms
2024-05-24T03:36:50.894Z|283386|jsonrpc|WARN|tcp:[<IP_ADDRESS>]:6642: send error: Broken pipe
2024-05-24T03:36:50.950Z|283387|ovn_northd|INFO|OVNSB commit failed, force recompute next time.
2024-05-24T03:36:50.972Z|283388|timeval|WARN|Unreasonably long 12072ms poll interval (12065ms user, 6ms system)
2024-05-24T03:36:50.972Z|283389|timeval|WARN|faults: 378 minor, 0 major
2024-05-24T03:36:50.972Z|283390|timeval|WARN|disk: 0 reads, 8 writes
2024-05-24T03:36:50.972Z|283391|timeval|WARN|context switches: 0 voluntary, 13 involuntary
2024-05-24T03:36:50.972Z|283392|coverage|INFO|Dropped 1 log messages in last 20 seconds (most recently, 20 seconds ago) due to excessive rate
2024-05-24T03:36:50.972Z|283393|coverage|INFO|Skipping details of duplicate event coverage for hash=ab6315f5
2024-05-24T03:36:50.972Z|283394|poll_loop|INFO|Dropped 2 log messages in last 19 seconds (most recently, 19 seconds ago) due to excessive rate
2024-05-24T03:36:50.975Z|283395|poll_loop|INFO|wakeup due to [POLLIN][POLLHUP] on fd 3 (/var/run/ovn/ovn-northd.595.ctl<->) at ../lib/stream-fd.c:157 (86% CPU usage)
2024-05-24T03:36:50.977Z|283396|poll_loop|INFO|wakeup due to [POLLIN] on fd 17 (<IP_ADDRESS>:24388<-><IP_ADDRESS>:6641) at ../lib/stream-fd.c:157 (86% CPU usage)
2024-05-24T03:36:50.980Z|283397|reconnect|WARN|tcp:[<IP_ADDRESS>]:6642: connection dropped (Broken pipe)
2024-05-24T03:36:50.980Z|283398|reconnect|INFO|tcp:[<IP_ADDRESS>]:6642: continuing to reconnect in the background but suppressing further logging
2024-05-24T03:36:50.980Z|283399|ovn_northd|INFO|ovn-northd lock lost. This ovn-northd instance is now on standby.
2024-05-24T03:36:50.981Z|283400|poll_loop|INFO|wakeup due to 0-ms timeout at tcp:[<IP_ADDRESS>]:6641 (86% CPU usage)
2024-05-24T03:36:50.981Z|283401|reconnect|INFO|tcp:[<IP_ADDRESS>]:6641: connection closed by peer
2024-05-24T03:36:51.981Z|283402|poll_loop|INFO|wakeup due to 1000-ms timeout at ../lib/reconnect.c:677 (86% CPU usage)
2024-05-24T03:36:51.981Z|283403|reconnect|INFO|tcp:[<IP_ADDRESS>]:6641: connecting...
2024-05-24T03:36:51.981Z|283404|reconnect|INFO|tcp:[<IP_ADDRESS>]:6641: connected
2024-05-24T03:36:51.994Z|283405|ovsdb_cs|INFO|tcp:[<IP_ADDRESS>]:6641: clustered database server is not cluster leader; trying another server
2024-05-24T03:36:51.994Z|283406|reconnect|INFO|tcp:[<IP_ADDRESS>]:6641: connection attempt timed out
2024-05-24T03:36:51.994Z|283407|reconnect|INFO|tcp:[<IP_ADDRESS>]:6641: waiting 2 seconds before reconnect
2024-05-24T03:36:53.996Z|283408|reconnect|INFO|tcp:[<IP_ADDRESS>]:6641: connecting...
2024-05-24T03:36:53.996Z|283409|reconnect|INFO|tcp:[<IP_ADDRESS>]:6641: connected
2024-05-24T03:36:54.007Z|283410|ovsdb_cs|INFO|tcp:[<IP_ADDRESS>]:6641: clustered database server is not cluster leader; trying another server
2024-05-24T03:36:54.007Z|283411|reconnect|INFO|tcp:[<IP_ADDRESS>]:6641: connection attempt timed out
2024-05-24T03:36:54.007Z|283412|reconnect|INFO|tcp:[<IP_ADDRESS>]:6641: waiting 4 seconds before reconnect
2024-05-24T03:36:58.008Z|283413|reconnect|INFO|tcp:[<IP_ADDRESS>]:6641: connecting...
2024-05-24T03:36:58.008Z|283414|reconnect|INFO|tcp:[<IP_ADDRESS>]:6641: connected
2024-05-24T03:36:58.981Z|283415|reconnect|INFO|tcp:[<IP_ADDRESS>]:6642: connected
2024-05-24T03:36:58.983Z|283416|ovn_northd|INFO|ovn-northd lock acquired. This ovn-northd instance is now active.
2024-05-24T03:36:58.984Z|283417|ovsdb_cs|INFO|tcp:[<IP_ADDRESS>]:6642: clustered database server is not cluster leader; trying another server
2024-05-24T03:36:58.984Z|283418|ovn_northd|INFO|ovn-northd lock lost. This ovn-northd instance is now on standby.
2024-05-24T03:37:06.987Z|283419|reconnect|INFO|tcp:[<IP_ADDRESS>]:6642: connected
2024-05-24T03:37:06.988Z|283420|ovn_northd|INFO|ovn-northd lock acquired. This ovn-northd instance is now active.
2024-05-24T03:37:06.988Z|283421|ovsdb_cs|INFO|tcp:[<IP_ADDRESS>]:6642: clustered database server is not cluster leader; trying another server
2024-05-24T03:37:06.988Z|283422|ovn_northd|INFO|ovn-northd lock lost. This ovn-northd instance is now on standby.
2024-05-24T03:37:14.989Z|283423|reconnect|INFO|tcp:[<IP_ADDRESS>]:6642: connected
2024-05-24T03:37:23.377Z|283424|ovn_northd|INFO|ovn-northd lock acquired. This ovn-northd instance is now active.
2024-05-24T03:37:23.867Z|283425|ovn_util|WARN|Dropped 21737 log messages in last 87 seconds (most recently, 35 seconds ago) due to excessive rate
2024-05-24T03:37:23.867Z|283426|ovn_util|WARN|all port tunnel ids exhausted
2024-05-24T03:37:33.870Z|283427|northd|ERR|Dropped 43475 log messages in last 88 seconds (most recently, 44 seconds ago) due to excessive rate
2024-05-24T03:37:33.871Z|283428|northd|ERR|lport fake-pod-7b99c6d54d-r87tb.fake-pod in port group node.kwok.node.545 not found.
2024-05-24T03:37:33.987Z|283429|inc_proc_eng|INFO|node: northd, recompute (forced) took 10610ms
2024-05-24T03:37:35.123Z|283430|inc_proc_eng|INFO|node: lflow, recompute (forced) took 846ms
2024-05-24T03:37:35.362Z|283431|jsonrpc|WARN|tcp:[<IP_ADDRESS>]:6642: send error: Broken pipe
2024-05-24T03:37:35.422Z|283432|ovn_northd|INFO|OVNSB commit failed, force recompute next time.
2024-05-24T03:37:35.442Z|283433|timeval|WARN|Unreasonably long 12064ms poll interval (12050ms user, 14ms system)
2024-05-24T03:37:35.442Z|283434|timeval|WARN|faults: 1405 minor, 0 major
2024-05-24T03:37:35.442Z|283435|timeval|WARN|disk: 0 reads, 8 writes
2024-05-24T03:37:35.442Z|283436|timeval|WARN|context switches: 0 voluntary, 12 involuntary
2024-05-24T03:37:35.442Z|283437|poll_loop|INFO|Dropped 3 log messages in last 44 seconds (most recently, 44 seconds ago) due to excessive rate
2024-05-24T03:37:35.444Z|283438|poll_loop|INFO|wakeup due to [POLLIN][POLLHUP] on fd 17 (/var/run/ovn/ovn-northd.595.ctl<->) at ../lib/stream-fd.c:157 (100% CPU usage)
2024-05-24T03:37:35.444Z|283439|poll_loop|INFO|wakeup due to [POLLIN] on fd 3 (<IP_ADDRESS>:24396<-><IP_ADDRESS>:6641) at ../lib/stream-fd.c:157 (100% CPU usage)
2024-05-24T03:37:35.445Z|283440|reconnect|WARN|tcp:[<IP_ADDRESS>]:6642: connection dropped (Broken pipe)
2024-05-24T03:37:35.445Z|283441|ovn_northd|INFO|ovn-northd lock lost. This ovn-northd instance is now on standby.
2024-05-24T03:37:35.446Z|283442|poll_loop|INFO|wakeup due to 0-ms timeout at tcp:[<IP_ADDRESS>]:6641 (100% CPU usage)
2024-05-24T03:37:35.446Z|283443|reconnect|INFO|tcp:[<IP_ADDRESS>]:6641: connection closed by peer
2024-05-24T03:37:36.445Z|283444|poll_loop|INFO|wakeup due to 999-ms timeout at ../lib/reconnect.c:677 (100% CPU usage)
2024-05-24T03:37:36.445Z|283445|reconnect|INFO|tcp:[<IP_ADDRESS>]:6642: connecting...
2024-05-24T03:37:36.446Z|283446|poll_loop|INFO|wakeup due to [POLLOUT] on fd 3 (<IP_ADDRESS>:27608<-><IP_ADDRESS>:6642) at ../lib/stream-fd.c:153 (100% CPU usage)
2024-05-24T03:37:36.446Z|283447|reconnect|INFO|tcp:[<IP_ADDRESS>]:6642: connected
2024-05-24T03:37:36.448Z|283448|poll_loop|INFO|wakeup due to 0-ms timeout at ../lib/reconnect.c:677 (100% CPU usage)
2024-05-24T03:37:36.448Z|283449|reconnect|INFO|tcp:[<IP_ADDRESS>]:6641: connecting...
2024-05-24T03:37:36.457Z|283450|ovsdb_cs|INFO|tcp:[<IP_ADDRESS>]:6642: clustered database server is not cluster leader; trying another server
2024-05-24T03:37:36.457Z|283451|reconnect|INFO|tcp:[<IP_ADDRESS>]:6642: connection attempt timed out
2024-05-24T03:37:36.457Z|283452|reconnect|INFO|tcp:[<IP_ADDRESS>]:6642: waiting 2 seconds before reconnect
2024-05-24T03:37:36.457Z|283453|poll_loop|INFO|wakeup due to [POLLOUT] on fd 17 (<IP_ADDRESS>:50250<-><IP_ADDRESS>:6641) at ../lib/stream-fd.c:153 (100% CPU usage)
2024-05-24T03:37:36.457Z|283454|reconnect|INFO|tcp:[<IP_ADDRESS>]:6641: connected
2024-05-24T03:37:36.467Z|283455|ovsdb_cs|INFO|tcp:[<IP_ADDRESS>]:6641: clustered database server is not cluster leader; trying another server
2024-05-24T03:37:36.467Z|283456|reconnect|INFO|tcp:[<IP_ADDRESS>]:6641: connection attempt timed out
2024-05-24T03:37:36.467Z|283457|reconnect|INFO|tcp:[<IP_ADDRESS>]:6641: waiting 2 seconds before reconnect
2024-05-24T03:37:38.458Z|283458|reconnect|INFO|tcp:[<IP_ADDRESS>]:6642: connecting...
2024-05-24T03:37:38.459Z|283459|reconnect|INFO|tcp:[<IP_ADDRESS>]:6642: connected
2024-05-24T03:37:38.459Z|283460|ovn_northd|INFO|ovn-northd lock acquired. This ovn-northd instance is now active.
2024-05-24T03:37:38.459Z|283461|ovsdb_cs|INFO|tcp:[<IP_ADDRESS>]:6642: clustered database server is not cluster leader; trying another server
2024-05-24T03:37:38.459Z|283462|reconnect|INFO|tcp:[<IP_ADDRESS>]:6642: connection attempt timed out
2024-05-24T03:37:38.459Z|283463|reconnect|INFO|tcp:[<IP_ADDRESS>]:6642: waiting 4 seconds before reconnect
2024-05-24T03:37:38.459Z|283464|ovn_northd|INFO|ovn-northd lock lost. This ovn-northd instance is now on standby.
2024-05-24T03:37:38.468Z|283465|reconnect|INFO|tcp:[<IP_ADDRESS>]:6641: connecting...
2024-05-24T03:37:38.468Z|283466|reconnect|INFO|tcp:[<IP_ADDRESS>]:6641: connected
2024-05-24T03:37:38.468Z|283467|ovsdb_cs|INFO|tcp:[<IP_ADDRESS>]:6641: clustered database server is not cluster leader; trying another server
2024-05-24T03:37:38.468Z|283468|reconnect|INFO|tcp:[<IP_ADDRESS>]:6641: connection attempt timed out
2024-05-24T03:37:38.468Z|283469|reconnect|INFO|tcp:[<IP_ADDRESS>]:6641: waiting 4 seconds before reconnect
2024-05-24T03:37:42.459Z|283470|reconnect|INFO|tcp:[<IP_ADDRESS>]:6642: connecting...
2024-05-24T03:37:42.460Z|283471|reconnect|INFO|tcp:[<IP_ADDRESS>]:6642: connected
2024-05-24T03:37:42.469Z|283472|reconnect|INFO|tcp:[<IP_ADDRESS>]:6641: connecting...
2024-05-24T03:37:42.469Z|283473|reconnect|INFO|tcp:[<IP_ADDRESS>]:6641: connected
2024-05-24T03:37:46.215Z|283474|ovn_northd|INFO|ovn-northd lock acquired. This ovn-northd instance is now active.

ovsdb-server-nb.log
2024-05-24T03:39:19.604Z|132818|timeval|WARN|Unreasonably long 1064ms poll interval (1055ms user, 7ms system)
2024-05-24T03:39:19.604Z|132819|timeval|WARN|faults: 1275 minor, 0 major
2024-05-24T03:39:19.604Z|132820|timeval|WARN|context switches: 0 voluntary, 3 involuntary
2024-05-24T03:39:19.604Z|132821|reconnect|ERR|tcp:<IP_ADDRESS>:29954: no response to inactivity probe after 5.18 seconds, disconnecting
2024-05-24T03:39:23.551Z|132822|timeval|WARN|Unreasonably long 1001ms poll interval (995ms user, 5ms system)
2024-05-24T03:39:23.551Z|132823|timeval|WARN|faults: 1278 minor, 0 major
2024-05-24T03:39:23.551Z|132824|timeval|WARN|context switches: 0 voluntary, 2 involuntary
2024-05-24T03:39:25.467Z|132825|reconnect|ERR|tcp:<IP_ADDRESS>:19996: no response to inactivity probe after 5 seconds, disconnecting
2024-05-24T03:39:27.612Z|132826|timeval|WARN|Unreasonably long 1055ms poll interval (1047ms user, 6ms system)
2024-05-24T03:39:27.612Z|132827|timeval|WARN|faults: 846 minor, 0 major
2024-05-24T03:39:27.612Z|132828|timeval|WARN|context switches: 0 voluntary, 1 involuntary
2024-05-24T03:39:31.655Z|132829|timeval|WARN|Unreasonably long 1006ms poll interval (996ms user, 7ms system)
2024-05-24T03:39:31.655Z|132830|timeval|WARN|faults: 843 minor, 0 major
2024-05-24T03:39:31.655Z|132831|timeval|WARN|context switches: 0 voluntary, 7 involuntary
2024-05-24T03:39:35.719Z|132832|timeval|WARN|Unreasonably long 1064ms poll interval (1060ms user, 4ms system)
2024-05-24T03:39:35.719Z|132833|timeval|WARN|faults: 846 minor, 0 major
2024-05-24T03:39:35.719Z|132834|timeval|WARN|context switches: 0 voluntary, 8 involuntary
2024-05-24T03:39:43.722Z|132835|timeval|WARN|Unreasonably long 1054ms poll interval (1049ms user, 4ms system)
2024-05-24T03:39:43.722Z|132836|timeval|WARN|faults: 812 minor, 0 major
2024-05-24T03:39:43.722Z|132837|timeval|WARN|context switches: 0 voluntary, 5 involuntary
2024-05-24T03:39:43.722Z|132838|reconnect|ERR|tcp:<IP_ADDRESS>:29956: no response to inactivity probe after 5.37 seconds, disconnecting
2024-05-24T03:39:47.684Z|132839|timeval|WARN|Unreasonably long 1010ms poll interval (1004ms user, 6ms system)
2024-05-24T03:39:47.685Z|132840|timeval|WARN|faults: 833 minor, 0 major
2024-05-24T03:39:47.685Z|132841|timeval|WARN|context switches: 0 voluntary, 1 involuntary
2024-05-24T03:39:51.734Z|132842|timeval|WARN|Unreasonably long 1053ms poll interval (1045ms user, 6ms system)
2024-05-24T03:39:51.734Z|132843|timeval|WARN|faults: 833 minor, 0 major
2024-05-24T03:39:51.734Z|132844|timeval|WARN|context switches: 0 voluntary, 1 involuntary
2024-05-24T03:39:53.735Z|132845|reconnect|ERR|tcp:<IP_ADDRESS>:20008: no response to inactivity probe after 5.01 seconds, disconnecting
2024-05-24T03:39:55.704Z|132846|timeval|WARN|Unreasonably long 1017ms poll interval (1012ms user, 5ms system)
2024-05-24T03:39:55.704Z|132847|timeval|WARN|faults: 838 minor, 0 major
2024-05-24T03:39:55.704Z|132848|timeval|WARN|context switches: 0 voluntary, 7 involuntary
2024-05-24T03:39:59.788Z|132849|timeval|WARN|Unreasonably long 1096ms poll interval (1091ms user, 3ms system)
2024-05-24T03:39:59.788Z|132850|timeval|WARN|faults: 834 minor, 0 major
2024-05-24T03:39:59.788Z|132851|timeval|WARN|context switches: 0 voluntary, 2 involuntary
2024-05-24T03:40:01.737Z|132852|reconnect|ERR|tcp:<IP_ADDRESS>:24442: no response to inactivity probe after 5 seconds, disconnecting
2024-05-24T03:40:03.731Z|132853|timeval|WARN|Unreasonably long 1033ms poll interval (1027ms user, 7ms system)
2024-05-24T03:40:03.731Z|132854|timeval|WARN|faults: 834 minor, 0 major
2024-05-24T03:40:03.731Z|132855|timeval|WARN|context switches: 0 voluntary, 1 involuntary
2024-05-24T03:40:07.776Z|132856|timeval|WARN|Unreasonably long 1071ms poll interval (1061ms user, 10ms system)
2024-05-24T03:40:07.776Z|132857|timeval|WARN|faults: 835 minor, 0 major
2024-05-24T03:40:07.776Z|132858|timeval|WARN|context switches: 0 voluntary, 7 involuntary
2024-05-24T03:40:07.776Z|132859|reconnect|ERR|tcp:<IP_ADDRESS>:29964: no response to inactivity probe after 5.62 seconds, disconnecting
2024-05-24T03:40:12.777Z|132860|reconnect|ERR|tcp:<IP_ADDRESS>:20022: no response to inactivity probe after 5 seconds, disconnecting
2024-05-24T03:40:15.777Z|132861|timeval|WARN|Unreasonably long 1060ms poll interval (1051ms user, 9ms system)
2024-05-24T03:40:15.777Z|132862|timeval|WARN|faults: 794 minor, 0 major
2024-05-24T03:40:15.777Z|132863|timeval|WARN|context switches: 0 voluntary, 2 involuntary
2024-05-24T03:40:15.778Z|132864|coverage|INFO|Dropped 12 log messages in last 56 seconds (most recently, 8 seconds ago) due to excessive rate
2024-05-24T03:40:15.778Z|132865|coverage|INFO|Skipping details of duplicate event coverage for hash=77dac2d1
2024-05-24T03:40:19.726Z|132866|timeval|WARN|Unreasonably long 1002ms poll interval (996ms user, 7ms system)
2024-05-24T03:40:19.726Z|132867|timeval|WARN|faults: 690 minor, 0 major
2024-05-24T03:40:19.726Z|132868|timeval|WARN|context switches: 0 voluntary, 1 involuntary
2024-05-24T03:40:22.250Z|132869|reconnect|ERR|tcp:<IP_ADDRESS>:24458: no response to inactivity probe after 5 seconds, disconnecting
2024-05-24T03:40:23.810Z|132870|timeval|WARN|Unreasonably long 1066ms poll interval (1061ms user, 4ms system)
2024-05-24T03:40:23.810Z|132871|timeval|WARN|faults: 685 minor, 0 major
2024-05-24T03:40:23.810Z|132872|timeval|WARN|context switches: 0 voluntary, 7 involuntary
2024-05-24T03:40:27.770Z|132873|timeval|WARN|Unreasonably long 1020ms poll interval (1015ms user, 5ms system)
2024-05-24T03:40:27.770Z|132874|timeval|WARN|faults: 473 minor, 0 major
2024-05-24T03:40:27.770Z|132875|timeval|WARN|context switches: 0 voluntary, 1 involuntary
2024-05-24T03:40:31.954Z|132876|timeval|WARN|Unreasonably long 1108ms poll interval (1100ms user, 8ms system)
2024-05-24T03:40:31.954Z|132877|timeval|WARN|faults: 801 minor, 0 major
2024-05-24T03:40:31.954Z|132878|timeval|WARN|context switches: 0 voluntary, 1 involuntary
2024-05-24T03:40:31.954Z|132879|reconnect|ERR|tcp:<IP_ADDRESS>:29966: no response to inactivity probe after 5.77 seconds, disconnecting

ovsdb-server-sb.log
2024-05-24T03:41:03.258Z|58044|jsonrpc|WARN|tcp:<IP_ADDRESS>:35724: receive error: Connection reset by peer
2024-05-24T03:41:03.258Z|58045|reconnect|WARN|tcp:<IP_ADDRESS>:35724: connection dropped (Connection reset by peer)
2024-05-24T03:41:05.466Z|58046|reconnect|ERR|tcp:<IP_ADDRESS>:24968: no response to inactivity probe after 5 seconds, disconnecting
2024-05-24T03:41:11.644Z|58047|reconnect|ERR|tcp:<IP_ADDRESS>:9754: no response to inactivity probe after 5 seconds, disconnecting
2024-05-24T03:41:22.055Z|58048|jsonrpc|WARN|tcp:<IP_ADDRESS>:35730: receive error: Connection reset by peer
2024-05-24T03:41:22.055Z|58049|reconnect|WARN|tcp:<IP_ADDRESS>:35730: connection dropped (Connection reset by peer)
2024-05-24T03:41:27.614Z|58050|reconnect|ERR|tcp:<IP_ADDRESS>:24970: no response to inactivity probe after 5 seconds, disconnecting
2024-05-24T03:41:34.818Z|58051|reconnect|ERR|tcp:<IP_ADDRESS>:9756: no response to inactivity probe after 5 seconds, disconnecting
2024-05-24T03:41:40.054Z|58052|jsonrpc|WARN|tcp:<IP_ADDRESS>:35734: receive error: Connection reset by peer
2024-05-24T03:41:40.054Z|58053|reconnect|WARN|tcp:<IP_ADDRESS>:35734: connection dropped (Connection reset by peer)
2024-05-24T03:41:41.840Z|58054|reconnect|ERR|tcp:<IP_ADDRESS>:8978: no response to inactivity probe after 5 seconds, disconnecting
2024-05-24T03:41:51.101Z|58055|reconnect|ERR|tcp:<IP_ADDRESS>:24972: no response to inactivity probe after 5 seconds, disconnecting
2024-05-24T03:41:56.430Z|58056|reconnect|ERR|tcp:<IP_ADDRESS>:9758: no response to inactivity probe after 5 seconds, disconnecting
2024-05-24T03:41:58.658Z|58057|jsonrpc|WARN|tcp:<IP_ADDRESS>:35738: receive error: Connection reset by peer
2024-05-24T03:41:58.658Z|58058|reconnect|WARN|tcp:<IP_ADDRESS>:35738: connection dropped (Connection reset by peer)
2024-05-24T03:42:10.905Z|58059|reconnect|ERR|tcp:<IP_ADDRESS>:24974: no response to inactivity probe after 5 seconds, disconnecting
2024-05-24T03:42:16.955Z|58060|jsonrpc|WARN|tcp:<IP_ADDRESS>:35742: receive error: Connection reset by peer
2024-05-24T03:42:16.955Z|58061|reconnect|WARN|tcp:<IP_ADDRESS>:35742: connection dropped (Connection reset by peer)
2024-05-24T03:42:19.908Z|58062|reconnect|ERR|tcp:<IP_ADDRESS>:9760: no response to inactivity probe after 5 seconds, disconnecting
2024-05-24T03:42:25.899Z|58063|reconnect|ERR|tcp:<IP_ADDRESS>:8998: no response to inactivity probe after 5 seconds, disconnecting
2024-05-24T03:42:34.622Z|58064|reconnect|ERR|tcp:<IP_ADDRESS>:24976: no response to inactivity probe after 5 seconds, disconnecting
2024-05-24T03:42:35.160Z|58065|jsonrpc|WARN|tcp:<IP_ADDRESS>:35746: receive error: Connection reset by peer
2024-05-24T03:42:35.160Z|58066|reconnect|WARN|tcp:<IP_ADDRESS>:35746: connection dropped (Connection reset by peer)
2024-05-24T03:42:40.127Z|58067|reconnect|ERR|tcp:<IP_ADDRESS>:9762: no response to inactivity probe after 5 seconds, disconnecting
2024-05-24T03:42:49.098Z|58068|reconnect|ERR|tcp:<IP_ADDRESS>:9008: no response to inactivity probe after 5 seconds, disconnecting
2024-05-24T03:42:53.460Z|58069|jsonrpc|WARN|tcp:<IP_ADDRESS>:35750: receive error: Connection reset by peer
2024-05-24T03:42:53.460Z|58070|reconnect|WARN|tcp:<IP_ADDRESS>:35750: connection dropped (Connection reset by peer)
2024-05-24T03:42:54.784Z|58071|reconnect|ERR|tcp:<IP_ADDRESS>:24978: no response to inactivity probe after 5 seconds, disconnecting
2024-05-24T03:43:04.102Z|58072|reconnect|ERR|tcp:<IP_ADDRESS>:9764: no response to inactivity probe after 5 seconds, disconnecting
2024-05-24T03:43:12.859Z|58073|jsonrpc|WARN|tcp:<IP_ADDRESS>:35754: receive error: Connection reset by peer
2024-05-24T03:43:12.859Z|58074|reconnect|WARN|tcp:<IP_ADDRESS>:35754: connection dropped (Connection reset by peer)
2024-05-24T03:43:18.411Z|58075|reconnect|ERR|tcp:<IP_ADDRESS>:24980: no response to inactivity probe after 5 seconds, disconnecting
2024-05-24T03:43:23.613Z|58076|reconnect|ERR|tcp:<IP_ADDRESS>:9766: no response to inactivity probe after 5 seconds, disconnecting
2024-05-24T03:43:31.133Z|58077|reconnect|ERR|tcp:<IP_ADDRESS>:9028: no response to inactivity probe after 5 seconds, disconnecting
2024-05-24T03:43:31.655Z|58078|jsonrpc|WARN|tcp:<IP_ADDRESS>:35758: receive error: Connection reset by peer
2024-05-24T03:43:31.655Z|58079|reconnect|WARN|tcp:<IP_ADDRESS>:35758: connection dropped (Connection reset by peer)
2024-05-24T03:43:37.376Z|58080|reconnect|ERR|tcp:<IP_ADDRESS>:24982: no response to inactivity probe after 5 seconds, disconnecting
2024-05-24T03:43:47.256Z|58081|reconnect|ERR|tcp:<IP_ADDRESS>:9768: no response to inactivity probe after 5 seconds, disconnecting
2024-05-24T03:43:50.057Z|58082|jsonrpc|WARN|tcp:<IP_ADDRESS>:35762: receive error: Connection reset by peer
2024-05-24T03:43:50.057Z|58083|reconnect|WARN|tcp:<IP_ADDRESS>:35762: connection dropped (Connection reset by peer)
2024-05-24T03:44:00.688Z|58084|reconnect|ERR|tcp:<IP_ADDRESS>:24984: no response to inactivity probe after 5 seconds, disconnecting
2024-05-24T03:44:06.345Z|58085|reconnect|ERR|tcp:<IP_ADDRESS>:9770: no response to inactivity probe after 5 seconds, disconnecting
2024-05-24T03:44:08.262Z|58086|jsonrpc|WARN|tcp:<IP_ADDRESS>:35766: receive error: Connection reset by peer
2024-05-24T03:44:08.263Z|58087|reconnect|WARN|tcp:<IP_ADDRESS>:35766: connection dropped (Connection reset by peer)
2024-05-24T03:44:15.098Z|58088|reconnect|ERR|tcp:<IP_ADDRESS>:9046: no response to inactivity probe after 5 seconds, disconnecting

看起来像tunnel id给用完了。如果是geneve的话，应该是2 的 16次方个

@cmdy https://kubeovn.github.io/docs/v1.12.x/reference/tunnel-protocol/#vxlan vxlan 数量会更少一些，单个 datapath 下 4096 个端口

根据 ovn 的架构文档 geneve 单个 datapath 最多支持 2**15 个端口


how do we see which image sku is multisession for AVD

Azure documentation issue guidance
This command gives list of images "az vm image list --all --output table -p MicrosoftWindowsDesktop -l westus --offer windows-10 --sku avd"
which sku is the multisession image in this list.  How to recognized the multisession or singlesession image?

@sdevathi-github
It would be great if you could add a link to the documentation you are following for these steps? This would help us redirect the issue to the appropriate team. Thanks!

@sdevathi-github
We are going to close this thread if there are any further questions regarding the documentation, please tag me in your reply and we will be happy to continue the conversation.


Deploy

In this project:

I deployed the repository using GitHub pages
I edited the web page so it will have a very good outline

I used linters to rid the code of errors

Hello @PinkMoon25 ,
Is it the link, uthmanbello.github.io/setup-and-mobile/, I am to put in the Live Demo part of the readme file?


Use slice::iter instead of into_iter to avoid future breakage

an_array.into_iter() currently just works because of the autoref
feature, which then calls <[T] as IntoIterator>::into_iter. But
in the future, arrays will implement IntoIterator, too. In order
to avoid problems in the future, the call is replaced by iter()
which is shorter and more explicit.
A crater run showed that your crate is affected by a potential future
change. See https://github.com/rust-lang/rust/pull/65819 for more information.

Thanks!

@sebcrozet Do you think this could be release as 0.21.1? Quite a few crates depend on ncollide, so getting this fix out as soon as possible would be really great :)


[FLINK-23547][build] run integration tests on install

Stateful Functions is missing the surefire maven plugin and integration tests, marked with ITCase suffix, are not executed on install.

Well, I guess the question is was this on purpose? I did find at least one existing ITCase for Unix sockets that never runs on CI

Thanks for the review, will address when merging


Bug: Field Numbers of Table Extension get prefixed now

Currently CRS (1.5.13) prefixes also Field Numbers...
My settings.json:
{
    "CRS.ObjectNamePrefix": "Prefix ",
    "CRS.OnSaveAlFileAction": "Rename"
}

What I enter:
tableextension 50006 "Prefix Sales Cr.Memo Header" extends "Sales Cr.Memo Header"
{
    fields
    {
        field(50021; "Prefix Test Field"; Code[20])
        {
            Caption = 'Test Field';
            DataClassification = CustomerContent;
        }
}

What CRS makes of it:
tableextension 50006 "Prefix Sales Cr.Memo Header" extends "Sales Cr.Memo Header"
{
    fields
    {
        field("Prefix 50021"; "Prefix Test Field"; Code[20])
        {
            Caption = 'Test Field';
            DataClassification = CustomerContent;
        }
}

Thanks for noticing - I'm on it!

Hm, I don't seem to be able to repro it :-/.

I wasn't able to repro it, but I've put an additional check to prevent this behavior..

vv1.5.14 is online - would be great that you report back...

Issue is gone. Thanks.


Types: Add back htmlFor + some camelCase

Fixes #1389 .

Coverage remained the same at 100.0% when pulling 635dca00e546113daa5510ad406c675b0408dfbd on html_for into 639bc321fc3800330c7f48421df0d26e32bf5204 on master.


Update dependencies.

The biggest change here is to upgrade client-go to v8.0.0. This adds support for kubeconfig exec plugins as used in the aws-iam-authenticator (confirmed locally).
This was my first time using govendor so let me know if I messed anything up.
Fixes https://github.com/wercker/stern/issues/80.

Ah, sorry I skimmed that and signed off my commit but haven't signed the OCA. I'll ping when that's done.

great, thanks!

I'm not sure I'll be able to do this anytime soon. So I'll close this PR for now. Please feel free to resubmit this work in a new PR.

@mattmoyer I was able to authenticate against kubernetes 1.9.8 + aws-iam-authenticator 0.3.0 but I got this error now:
Error opening stream to ${NAMESPACE}/${POD}: ${DEPLOYMENT}
: PodLogOptions "${POD}" is invalid: sinceSeconds: Invalid value: 0: must be greater than 0

@michalschott Did you specify --since option?

@guoyongzhang no I don't. Worked OK if I used a value there, so I assume is set to 0 by default.


Separate bundle from configuration

Description
Separate bundle from configuration (api, clientIds etc).
The goal is to have a bundle with no configuration, it would be uploaded separately.
DevServer, though, needs some default config to run.
With webpack, it could be done by including followint into webpack.base.
  devServer: {
    contentBase: path.join(__dirname, "public")
  },

Where public includes dev config when running devServer but build doesn't include any config.
As a result, we could promote the same artifact to different stages with just having proper configs loaded specific to the stage separately.
Unfortunately, devServer part seems to be ignored.
Other ways: with webpack.base externals and !file-loader seems to always include config file into bundle.
Steps to reproduce
Steps to reproduce the behavior:
N/A
Expected behavior
A way to separate configuration and load it only for DevServer
Screenshots
Versions

React-Boilerplate: 4.0.0
Node/NPM: 6.9
Browser: Chrome

I'm not entirely sure what you're trying to do. Take a look at #2617. Maybe my suggestion there can help you?
Either way, the issue tracker is meant for bug reports and features requests. Personal help requests should be directed to our Spectrum (or StackOverflow or any other relevant forum).
Good luck!

So not supporting devServer in webpack config is not a bug?
ok...

My apologies if I seem dismissive. Here's why:
a. Your issue description does not do a very good job of explaining what you're trying to do. I took a guess and shared a suggestion that I believe might help you. Did you look at it?
b. react-boilerplate doesn't affect your ability to use the devServer option in Webpack. However, it's just a dev option, it has no effect on how build works.
c. This is a request for personal help, not an actual issue with the boilerplate. The Issue Tracker is for Bug Reports and Feature Requests only.


solo5: add missing __arch_time_now to solo5 platform

Adding missing __arch_time_now implementation to solo5. This was broken after 5b90cfc277c3284c9d2b6c65f605e5bc7282eff9. Will work on something for #1521
Question: the returned time should be in nanoseconds right?
Tested with test_ukvm.sh on an ubuntu:16.04 container.

its the wallclock time, but theres no reason we cant just decide its in nanos, since it should fit nicely in 64-bits, right?

Thanks @fwsGonzo , changed the call to solo5_clock_wall, which returns the wall clock time in nanoseconds since the UNIX epoch.


improvement to error message for GROUP BY with too many points

> select count(value) from system_load5 where time > now() - 100w group by time(10m)
ERR: too many points in the group by interval. maybe you forgot to specify a where time clause?

I specified a WHERE time clause, but it was 100 weeks vs 10 minute buckets. I suggest updating the error message to something like:
ERR: too many points in the group by interval. maybe you forgot to specify a where time clause or your group by intervals are too short compared to the where time range?

Perhaps also some help on what is too much for the time interval.
This returns a series of aggregated points:
> select count(value) from system_load5 where time > now() - 99w - 1d group by time(10m)
name: system_load5
------------------
time			count
2013-07-04T22:30:00Z
2013-07-04T22:40:00Z
2013-07-04T22:50:00Z
2013-07-04T23:00:00Z
...
2015-05-29T21:50:00Z	43
2015-05-29T22:00:00Z	18
2015-05-29T22:10:00Z	43
2015-05-29T22:20:00Z	43
2015-05-29T22:30:00Z	8

whereas going back one extra day is too much:
> select count(value) from system_load5 where time > now() - 99w - 2d group by time(10m)
ERR: too many points in the group by interval. maybe you forgot to specify a where time clause?

694 days of 10m buckets is fine, and equates to 99,936 buckets. 695 days of 10m buckets is 100,080 buckets. Looks like 100k is the bucket limit.
Verifying:
> select count(value) from system_load5 where time > now() - 99w - 1d - 10h - 39m group by time(10m)
name: system_load5
------------------
time			count
2013-07-04T12:00:00Z
2013-07-04T12:10:00Z
...
2015-05-29T22:20:00Z	43
2015-05-29T22:30:00Z	39

> select count(value) from system_load5 where time > now() - 99w - 1d - 10h - 40m group by time(10m)
ERR: too many points in the group by interval. maybe you forgot to specify a where time clause?

99 weeks plus 1 day plus 10 hours plus 40 minutes is 1,000,000 minutes, which is 100k buckets of 10 minutes each. Remove one minute and the number of buckets drops to 99,999 and the query executes.
With that I propose something like the following error message:
 ERR: too many points in the group by interval. adjust the where clause or the group by interval to return fewer than 100k buckets.

You are correct, 100k is the limit. https://github.com/influxdb/influxdb/blob/de77ee18969e56b447988c25c3bdc37347e3df0c/influxql/engine.go#L20

Just noticed that the query
SELECT count(value)
FROM heartrate
WHERE time < now()
GROUP BY time(1m)

yields
name: heartrate
----------------
time			count
1970-01-01T00:00:00Z

whereas the query
SELECT count(value)
FROM heartrate
WHERE time > now() - 99w - 2d
GROUP BY time(10m)

yields
ERR: too many points in the group by interval. maybe you forgot to specify a where time clause?

I would expect the first query to give a similar response. Is this incorrect?

I'm closing this since it doesn't seem valid with the new query engine. The bucket limit has a different error message and is an optional flag that people can pass to the config.
Please reopen if there's more we need to do on this. Thanks.


Update main.py

Scan submitted to Checkmarx

Checkmarx SAST - Scan Summary & Details
Cx-SAST Summary
Total of 10 vulnerabilities
 1 High
 5 Medium
 4 Low
 0 Info
Violation Summary
 1 High
View more details on Checkmarx UI

Scan failed due to some error.


add grid-list.spec.ts test for switching between ratio and fixed height

This creates a unit tests that demonstrates bug #4047
In theory, all permutations of switching between ratio, fixed, and fit should be tested, but that's probably overkill.

I came-up with a fix that passes the test, but someone more familiar with TileStylers code should probably look at this bug.


!omen command

Responds to users with ominous bullshit........

I have a bad feeling about this.
Want to squash the commits up and add em to the lint section in the package.json?

@LinuxMercedes I fixed those blasphemous ellipses.
@euank I'm not sure what you mean by adding to the lint section. I ran npm run lint and it only complained about other files.
~/Code/opensource/EuIrcBot (drusepth-patch-1)$ npm run lint

><EMAIL_ADDRESS>lint /Users/abrown/Code/opensource/EuIrcBot
> eslint $(git ls-files | grep -E '\.js$' | grep -E '^(bot.js|index.js|modules/bully.js|modules/featurerequest.js|modules/mastodon|modules/schedule|modules/nickserv.js|modules/test2.js)')

/Users/abrown/Code/opensource/EuIrcBot/modules/bully.js
  3:28  warning  Unexpected unnamed function  func-names

/Users/abrown/Code/opensource/EuIrcBot/modules/nickserv.js
  8:23  warning  Unexpected unnamed function  func-names

/Users/abrown/Code/opensource/EuIrcBot/modules/test2.js
  5:22  warning  Unexpected unnamed function  func-names

✖ 3 problems (0 errors, 3 warnings)

~/Code/opensource/EuIrcBot (drusepth-patch-1)$ git status

I'm happy to squash and force-push, but GitHub also provides a "Squash and merge" function we can use on the Merge pull request button. ⛄

@drusepth since the lint regex in package.json doesn't include modules/omen, this file sin't being checked by that command. That's what I meant.

I'm happy to squash and force-push, but GitHub also provides a "Squash and merge" function we can use on the Merge pull request button

I prefer not using that squash-and-meg github feature since it requires me interpreting what the correct combination of messages is, I'm not sure how it deals with ownership, it prevents commit signing, and it's a very course granularity (can only squash down to one commit).


add client side TLS support

Add client side TLS.
The test cases are added into a separate module (spring-cloud-netflix-eureka-client-tls-tests) because it depends on both:

spring-cloud-netflix-eureka-client
spring-cloud-netflix-eureka-server

Because there is one test case failure in spring-cloud-netflix-eureka-client (before my change), the PR build will not pass. However, I runned the test cases in spring-cloud-netflix-eureka-client-tls-tests and they all pass.

If I am not mistaken, eureka server already depends on eureka client

The test code is for changes in spring-cloud-netflix-eureka-client, if it's ok to put the test code in spring-cloud-netflix-eureka-server, I can change it.
The purpose of this PR is to allow TLS client side cert to be configurable for eureka client.

@ryanjbaxter @spencergibb , what's your suggestion to put the test code (which tests eureka-client) into eureka-server?

Create a separate PR on 2.2.x branch: https://github.com/spring-cloud/spring-cloud-netflix/pull/3865
Close this one.


API Version?

I'm looking, for example, at the resulting code for creating a customer and seeing some significant discrepancies from the XML specified in API documentation for Creating Customers.  Is the gem targeted at a (possibly older) version of the Inacct API.
Any assistance you could provide would be greatly appreciated.

@erichhorde
When we create a customer, the call looks something like:
def activate
  request = Request.new(AUTHENTICATION_ATTRIBUTES)
  request.create :customer, customer_attrs
  send_request request
end

private

def customer_attrs
  {
    customerid: @client.id,
    name:       @client.name,
    status:     customer_status,
    custrepid:  @client.managing_director_id,
    displaycontact: {
      printas:    @client.name,
      first_name: @client.first_name,
      last_name:  @client.last_name,
      email1:     @client.email
    }
  }
end

def customer_status
  'active'
end

Where AUTHENTICATION_ATTRIBUTES and send request both live in a base gateway and look like:
AUTHENTICATION_ATTRIBUTES = {
      companyid:       ENV['...'],
      userid:          ENV['...'],
      user_password:   ENV['...'],
      senderid:        ENV['...'],
      sender_password: ENV['...']
    }.freeze

def send_request(request)
  request.send
  rescue => error
    Honeybadger.notify error_with_function_context(error, request.functions)
end

This gem works with the current Intacct API version. It was written with the intention of the integrating with the old Intacct API, which was changed sometime around late spring/early summer 2017.


Create Column Pesticide Designate/Nullable Event ID

To meet client requirements for how GAs handle Pesticide Exams, the csr model required a new field, 'pesticide_designate'. This column will allow for the pesticide option in the non-ita exam create modal to be broken away, to make a new crete exam option only for pesticide exams. This PR also contains an update to the exam model, making event ID nullable. This change was made due to the timing of Scott Rumsby working on something that required this change while I was making the required changes to the CSR model.

Forgot to mention that I tested setting a CSR to pesticide_designate=1 on the admin panel and it worked.


[#6430] Adaptive ForEachElement does not exit when child action CancelAllDialogs is called

Fixes # 6430
#minor
Description
This PR fixes the issue in the ForEachElement action that wasn't exiting the loop after a call to the CancelAllDialogs action.
The fix also considers the nested ForEachElement loops scenario.
Specific Changes

Updated the ShouldEndDialog method of the ForEachElement class to consider also Cancelled status as well as Complete to end the dialogs.
Added a unit test in the ActionTests class to cover the nested ForEachElement's loops with a CancelAllDialogs call scenario.
Added the Action_Foreach_Nested_WithCancel.test.dialog test script.

Testing
These images show the issue fixed after the changes.

/promoted 6452


feat: merge rule result in RuleMode

Codecov Report

Merging #135 (bc077ed) into master (8006f03) will increase coverage by 0.538%.
The diff coverage is 59.006%.

@@               Coverage Diff               @@
##              master      #135       +/-   ##
===============================================
+ Coverage     33.096%   33.635%   +0.538%
- Complexity       906       909        +3
===============================================
  Files            192       197        +5
  Lines           9137      9181       +44
  Branches        2273      2249       -24
===============================================
+ Hits            3024      3088       +64
+ Misses          5454      5442       -12
+ Partials         659       651        -8

Flag
Coverage Δ

unittests
33.635% <59.006%> (+0.538%)
:arrow_up:

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

...ain/kotlin/com/itangcent/common/utils/Functions.kt
0.000% <0.000%> (ø)

.../main/kotlin/com/itangcent/common/utils/Streams.kt
14.035% <0.000%> (-0.510%)
:arrow_down:

.../com/itangcent/intellij/config/rule/BooleanRule.kt
28.000% <0.000%> (-5.333%)
:arrow_down:

...in/com/itangcent/intellij/config/rule/EventRule.kt
50.000% <0.000%> (+50.000%)
:arrow_up:

.../kotlin/com/itangcent/intellij/config/rule/Rule.kt
0.000% <0.000%> (ø)

...com/itangcent/intellij/config/rule/RuleComputer.kt
50.000% <ø> (ø)

...tlin/com/itangcent/intellij/config/rule/RuleKey.kt
0.000% <ø> (ø)

...n/com/itangcent/intellij/config/rule/RuleLookUp.kt
100.000% <ø> (ø)

...om/itangcent/intellij/config/rule/SimpleRuleKey.kt
32.432% <0.000%> (-27.568%)
:arrow_down:

...n/com/itangcent/intellij/config/rule/StringRule.kt
27.273% <0.000%> (-15.584%)
:arrow_down:

... and 17 more

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 8006f03...bc077ed. Read the comment docs.


Unimplementable methods can be rendered in interfaces

While working on gtksourceview bindings, I've discovered that sometimes methods can be rendered in an interface which cannot be implemented. When this happens, the generated bindings fail to build, because the method in the interface is not implemented anywhere. Missing methods may be a problem, but I thought I'd file this issue as there is a broader issue here -- the method probably shouldn't to be rendered in the interface if it can't be implemented.
When I ran into this it happened because the return type of the method couldn't be converted from an internal to a public type (ie ReturnTypeToManagedExpression.Render() was throwing). This check was occurring when the method was being rendered in a class, but not when rendered in an interface.

This affects functions without an interface, too. To fix this the public return type renderer and the expression renderer for public return types must support the same feature set.
This means that the fallback parameter must be removed for the public return type renderer and the code should look like the expression renderer.


pyhdk import fails on the HDK 0.9 from conda

I have a problem with the latest conda release of HDK.
Source code to reproduce:
import pyhdk

pyhdk.init()

Error msg:
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x00007feb5ac04210, pid=503413, tid=503526
#
# JRE version: OpenJDK Runtime Environment (11.0.1+13) (build 11.0.1+13-LTS)
# Java VM: OpenJDK 64-Bit Server VM (11.0.1+13-LTS, mixed mode, tiered, compressed oops, g1 gc, linux-amd64)
# Problematic frame:
# C  [libjimage.so+0x4210]  ImageStrings::find(Endian*, char const*, int*, unsigned int)+0x70
#
# Core dump will be written. Default location: Core dumps may be processed with "/usr/share/apport/apport -p%p -s%s -c%c -d%d -P%P -u%u -g%g -- %E" (or dumping to /localdisk/ekrivov/db-benchmark/modin/core.503413)
#
# An error report file with more information is saved as:
# /localdisk/ekrivov/db-benchmark/modin/hs_err_pid503413.log
#
# If you would like to submit a bug report, please visit:
#   http://www.azulsystems.com/support/
#
Aborted (core dumped)

Code to reproduce after creating hdk_bug.py with source code from above:
#!/bin/bash
set -e

curl -o install_miniconda.sh -L https://repo.anaconda.com/miniconda/Miniconda3-py311_23.9.0-0-Linux-x86_64.sh && \
    sh install_miniconda.sh -u -b -p ./miniconda && \
    rm -f install_miniconda.sh

source ./miniconda/bin/activate
conda install -y conda-libmamba-solver

# install binaries
conda install -y -c conda-forge modin-hdk --solver=libmamba

python hdk_bug.py

Probably this is the reason - https://github.com/conda-forge/hdk-feedstock/commit/7a402c0a1b01710a65ac4a40ea31222e1bedb471

I can confirm updating to openjdk 17 fixes this issue. So, we need to modify conda-forge to pin openjdk >= 17 instead of 11. I will open the conda-forge PR and report back.

https://github.com/conda-forge/hdk-feedstock/pull/54 @Garra1980 @leshikus please take a look.


Update Spine to 1.0.0-pre6

This PR updates the Spine dependencies to version 1.0.0-pre6 and releases the respective version of gcloud-java.

@armiol, PTAL.


Simplify deployment and configuration

Aim to have a very easy and simple experience when deploying and configuring traefik on SF

@lawrencegripper  do you still need help, I may be able to help on that

Would love some help with this, at a high level the aim would be to take the existing Readme and work to simplify the process of getting Traefik up and running in the cluster. That may be through scripting, changes to the existing code or other techniques we've not considered.
I think a good first step would be to come up with some proposals and we can chat through them in more detail - sound good?

As a part of this I am trying to remove the requirement of having to drop certs in 'certs' folder. Instead they should be auto picked from LocalMachine or KeyVault. This makes it easy to solve scenarios like using SSL, using MTLS etc.
PR - https://github.com/jjcollinge/traefik-on-service-fabric/pull/65


make all does not recompile when a header file changed

Expected Behavior
Would like when code changes make burn creates image with that change
Actual Behavior
If only ccconfig.h is changed. ie NUM_LIN_LEDS from 6 to 16
make burn or make all does not see this, so make burn just burns previous image
So in this case must first run make clean.
Is there anyway for the makefile to tell if ccconfig.h gets changed?
Tested other .h files and the same things happens.
Related:
https://stackoverflow.com/questions/44020890/gnu-make-does-not-recompile-when-a-header-file-changed

Not recompiling is expected behavior for the way the makefile is written. The same thing happens if you modify anything in the makefile's DEFINES_LIST. It's somewhat rare that the only change occurs in a header file, but you've found one case.
If you want to modify the makefile to recompile header-only changes, go for it. This project is small enough that recompiling the whole thing isn't troublesome.
Also related: https://nathandumont.com/blog/automatically-detect-changes-in-header-files-in-a

This should be resolved with efad4b88a1a4d737751541d0b54f3ce6c8f2c2e9


Support for Anchor Types in the Rust renderer

With Anchor 0.30.0, IDLs are more dynamically generated using the IDL build trait. This is itself embedded in the AnchorSerialize trait. This PR providers a choice between Anchor and Borsh serialization to make it easier to interface between Anchor and MPL programs.

Hey Keith, thanks for the PR! That makes sense. Do you know if that would be an issue with types imported from the kaigan crate? I'm not too sure but I think these only provide implementations for Borsh traits. Might be worth adding Anchor trait implementations in Kaigan too?

Nope, we've been testing this on Core. The traits are nearly identical because Anchor serde is basically Borsh anyway.

@blockiosaurus Nice! Could you please add the following to ./test/packages/rust/Cargo.toml?

anchor = ["dep:anchor-lang"] under the [features] section.
anchor-lang = { version = "0.30.0", optional = true } in the [dependencies] section.

If I understood correctly, this is needed to use the generated types on Anchor structs, so the Anchor IDL generation works. We might need to add something similar to Kaigan.
Core does not use Kaigan types, so it won't show whether there is a problem or not. Any chance you can try on Bubblegum to see what happens?

Thanks! Tracking that in a separate issue.

FYI - using the new idl-build feature with Kaigan types currently does not work.

Yup, tracking it as mentioned in the previous comment.

Whoops just saw your message. Kinobi is published, but kaigan is pretty messy so I'm planning on doing that in a follow up release this sprint or next.


Per user credentials and storage

Background: https://airtable.com/tblD3oZPLJgGhCmch/viw5Jsp2TrY3it9Yr/recmpemZRTlOs3HUS
PM: @rolandcrosby
Eng partner: @mberhault

Moved out of scope for 2.2.

Closing this issue for now - will open when it is added to the roadmap.


Custom GraphQL Transformer v2 - Error: template.substitueValues is not a function

How did you install the Amplify CLI?
curl
If applicable, what version of Node.js are you using?
v18.16.1
Amplify CLI Version
12.1.1
What operating system are you using?
Mac 13.4.1
Did you make any manual changes to the cloud resources managed by Amplify? Please describe the changes made.
No manual changes made
Describe the bug
I have a custom Custom Transformer v2 which was running well for a very long time. It ist now crashing with the message template.substitueValues is not a function.
The error is produced by this lines:
resolver.addToSlot(
  "auth",
  MappingTemplate.s3MappingTemplateFromString(
    snippet,
    `Mutation.createTodo.{slotName}.{slotIndex}.req.vtl`
  )
);

MappingTemplate.s3MappingTemplateFromString() generates a template including a function substitueValues(). When executing amplify push api it seems that for Amplify CLI this function does not exist in the template object.
But according to the current source code of<EMAIL_ADDRESS>should!
Interestingly if you look at packages/amplify-graphql-transformer-core/src/transformer-context/resolver.ts there is a reference to a bugfix of an issue I raised by myself. So template.substitueValues  was actually created to solve this!
// Check the constructor name instead of using 'instanceof' because the latter does not work
// with copies of the class, which happens with custom transformers.
// See: https://github.com/aws-amplify/amplify-cli/issues/9362

Due to this issue I cannot deploy my API anymore which is an absolute nightmare! I cannot even continue to work locally. 😥
Thank you for looking into this, appreciating any workaround or fix!
Expected behavior
Custom Transformers V2 should be able to add slots to resolvers correctly without throwing template.substitueValues is not a function
resolver.addToSlot(
  "auth",
  MappingTemplate.s3MappingTemplateFromString(
    snippet,
    `Mutation.createTodo.{slotName}.{slotIndex}.req.vtl`
  )
);

Reproduction steps

Init amplify
Create GraphQL API with Basic Cognito Auth and the Demo "Todo" GraphQL Schema (see below)
Create a Custom Transformer (code below), configure transform.conf.json, add @Tenant directive to GraphQL Schema (see below)
Run amplify push

GraphQL Schema
type Todo @model @tenant @auth(rules: [{ allow: private }]) {
  id: ID!
  name: String!
  description: String
}

Sample Transformer
import {
  MappingTemplate,
  TransformerPluginBase,
} from "@aws-amplify/graphql-transformer-core";
import {
  TransformerContextProvider,
  TransformerSchemaVisitStepContextProvider,
} from "@aws-amplify/graphql-transformer-interfaces";
import { DirectiveNode, ObjectTypeDefinitionNode } from "graphql";
import { printBlock, raw } from "graphql-mapping-template";

const directiveName = "tenant";
const directiveDefinition = `
  directive @${directiveName} on OBJECT
`;

export class TenantTransformer extends TransformerPluginBase {
  private typesWithModelDirective: Set<string> = new Set();

  constructor() {
    super("tenant-transformer", directiveDefinition);
  }

  object = (
    definition: ObjectTypeDefinitionNode,
    directive: DirectiveNode,
    ctx: TransformerSchemaVisitStepContextProvider
  ): void => {
    const typeName = definition.name.value;
    this.typesWithModelDirective.add(typeName);
  };

  generateResolvers = (ctx: TransformerContextProvider): void => {
    const resolver = ctx.resolvers.getResolver("Mutation", "createTodo");
    if (resolver) {
      const snippet = printBlock(
        `Debug: Check if @tenant directive find its way to a VTL file`
      )(raw("$util.unauthorized()"));

      # The error originates here
      resolver.addToSlot(
        "auth",
        MappingTemplate.s3MappingTemplateFromString(
          snippet,
          `Mutation.createTodo.{slotName}.{slotIndex}.req.vtl`
        )
      );
    }
  };
}

Package.json of my sample transformer
{
  "name": "tenant-transformer",
  "author": "jgo",
  "version": "1.0.0",
  "private": true,
  "main": "dist/index.js",
  "scripts": {
    "dev":"tsc -w",
    "postinstall": "tsc"
  },
  "dependencies": {
    "@aws-amplify/graphql-transformer-core": "^1.3.8",
    "aws-cdk-lib": "^2.80.0",
    "constructs": "^10.0.5"
  },
  "devDependencies": {
    "@types/node": "*",
    "typescript": "*"
  }
}

Project Identifier
No response
Log output

# Put your logs below this line

2023-07-20T08:35:52.944Z|info : amplify push core
2023-07-20T08:35:53.033Z|info : @aws-amplify/amplify-cli-core.banner-message/index.ts.fetch banner messages from https://aws-amplify.github.io/amplify-cli/banner-message.json({}
2023-07-20T08:35:54.207Z|info : amplify-provider-awscloudformation.system-config-manager.getProfileConfig(["default"])
2023-07-20T08:35:54.209Z|info : amplify-provider-awscloudformation.system-config-manager.getProfiledAwsConfig.profileConfig([{"region":"eu-central-1"}])
2023-07-20T08:35:54.209Z|info : amplify-provider-awscloudformation.system-config-manager.getProfileCredentials(["default"])
2023-07-20T08:35:54.216Z|info : amplify-provider-awscloudformation.zip-util.downloadZip.s3.getFile([{"Key":"[***]rent-[***]ud-[***]d.zip"},null])
2023-07-20T08:35:54.218Z|info : amplify-provider-awscloudformation.aws-s3.s3.getFile([{"Key":"[***]rent-[***]ud-[***]d.zip","Bucket":"[***]ify-[***]re-[***]ev-[***]34-[***]ment"}])
2023-07-20T08:35:54.448Z|info : amplify-provider-awscloudformation.initialize-env.run.cfn.updateamplifyMetaFileWithStackOutputs([{"StackName":"[***]ify-[***]re-[***]ev-[***]34"}])
2023-07-20T08:35:54.450Z|info : amplify-provider-awscloudformation.system-config-manager.getProfileConfig(["default"])
2023-07-20T08:35:54.451Z|info : amplify-provider-awscloudformation.system-config-manager.getProfiledAwsConfig.profileConfig([{"region":"eu-central-1"}])
2023-07-20T08:35:54.451Z|info : amplify-provider-awscloudformation.system-config-manager.getProfileCredentials(["default"])
2023-07-20T08:35:54.456Z|info : amplify-provider-awscloudformation.aws-cfn.updateamplifyMetaFileWithStackOutputs.cfn.listStackResources([{"StackName":"[***]ify-[***]re-[***]ev-[***]34"}])
2023-07-20T08:35:54.643Z|info : amplify-provider-awscloudformation.aws-cfn.describeStack.cfn.describeStacks([{"StackName":"[***]ify-[***]re-[***]ev-[***]34"}])
2023-07-20T08:35:54.782Z|info : amplify-provider-awscloudformation.aws-s3.s3.getFile([{"Key":"[***]ify-[***]json","Bucket":"[***]ify-[***]re-[***]ev-[***]34-[***]ment"}])
2023-07-20T08:35:55.887Z|info : amplify-provider-awscloudformation.system-config-manager.getProfileConfig(["default"])
2023-07-20T08:35:55.889Z|info : amplify-provider-awscloudformation.system-config-manager.getProfiledAwsConfig.profileConfig([{"region":"eu-central-1"}])
2023-07-20T08:35:55.889Z|info : amplify-provider-awscloudformation.system-config-manager.getProfileCredentials(["default"])
2023-07-20T08:35:58.174Z|error : template.substitueValues is not a function
DeploymentFault: template.substitueValues is not a function

</details>

### Additional information

_No response_

### Before submitting, please confirm:

- [X] I have done my best to include a minimal, self-contained set of instructions for consistently reproducing the issue.
- [X] I have removed any sensitive information from my code snippets and submission.

@johnpc maybe you have an idea on this as you helped out fixing the original problem causing this bug in #10188 ?
Thank you for having a look 🙏

I think I have spottet the problem!
In<EMAIL_ADDRESS>someone fixed a "typo" from substitueValuesto substituteValues in these both files here:
https://github.com/aws-amplify/amplify-category-api/compare/@aws-amplify/graphql-transformer-core@1.3.4<EMAIL_ADDRESS>packages/amplify-graphql-transformer-core/src/transformer-context/resolver.ts
But the Amplify CLI is still trying to invoke template.substitueValues, therefore substitueValues is undefined and the error template.substitueValues is not a function is thrown!
Can you please check? Thx!

Hey, 👋 thanks for raising this! I'm going to transfer this over to our API repository for better assistance 🙂.