Helm upgrade failing since 2.12

Helm keeps failing since 2.12 when you add a new resource to an existing chart, it succeeds first time but it fails sequentially after the first helm upgrade. On 2.14.1 the error message is prettier but the error continues.
helm upgrade processei processei-1.1.tgz
Release "processei" has been upgraded.
LAST DEPLOYED: Fri Jun 14 22:15:26 2019
NAMESPACE: default
STATUS: DEPLOYED
RESOURCES:
==> v1/ConfigMap
NAME                                DATA  AGE
processei-nginx-ingress-controller  5     137d
==> v1/Deployment
NAME                 READY  UP-TO-DATE  AVAILABLE  AGE
processei-pgbouncer  1/1    1           1          3s
==> v1/PersistentVolume
NAME        CAPACITY  ACCESS MODES  RECLAIM POLICY  STATUS     CLAIM                         STORAGECLASS  REASON  AGE
postgresql  25Gi      RWO           Retain          Bound      default/processei-postgresql  postgresql    137d
rabbitmq    8Gi       RWO           Retain          Available  rabbitmq                      137d
==> v1/PersistentVolumeClaim
NAME                  STATUS  VOLUME      CAPACITY  ACCESS MODES  STORAGECLASS  AGE
processei-postgresql  Bound   postgresql  25Gi      RWO           postgresql    137d
==> v1/Pod(related)
NAME                                                      READY  STATUS   RESTARTS  AGE
processei-captcha-85754bbc88-qswj7                        1/1    Running  6         7d20h
processei-cronos-65f555f99-8dp9r                          1/1    Running  0         3h44m
processei-nginx-ingress-controller-775bc6d4b7-kmmkq       1/1    Running  0         7d19h
processei-nginx-ingress-default-backend-7fb678dbdc-hsjgk  1/1    Running  3         29d
processei-notifications-notifications-f7fbd7b68-lxbr4     1/1    Running  0         3h44m
processei-pgbouncer-689d6cb76d-fpxtz                      2/2    Running  0         2s
processei-postgresql-b449c7f5-dscm7                       2/2    Running  0         3h44m
processei-processei-68bbf8544b-shgzr                      1/1    Running  0         31m
processei-worker-api-8997986d6-5sgf9                      1/1    Running  0         3h44m
processei-worker-api-8997986d6-ln9cd                      1/1    Running  0         3h43m
processei-worker-api-8997986d6-m64jv                      1/1    Running  0         3h44m
rabbitmq-0                                                1/1    Running  7         137d
==> v1/Secret
NAME                  TYPE    DATA  AGE
bounceruri            Opaque  4     3s
processei-postgresql  Opaque  1     137d
==> v1/Service
NAME                                     TYPE       CLUSTER-IP     EXTERNAL-IP  PORT(S)                                      AGE
db-postgresql                            NodePort   <IP_ADDRESS>          5432:5432/TCP                                137d
pgbouncer-service                        ClusterIP  <IP_ADDRESS>         5432/TCP,9127/TCP                            3s
processei-nginx-ingress-controller       NodePort   <IP_ADDRESS>         80:80/TCP,443:443/TCP                        137d
processei-nginx-ingress-default-backend  NodePort   <IP_ADDRESS>         80:28100/TCP                                 137d
rabbitmq                                 NodePort   <IP_ADDRESS>           5672:5672/TCP,4369:6170/TCP,25672:24324/TCP  137d
rabbitmq-management                      NodePort   <IP_ADDRESS>         15672:31059/TCP                              137d
service-captcha                          NodePort   <IP_ADDRESS>          80:25218/TCP                                 137d
service-cronos                           NodePort   <IP_ADDRESS>          80:28721/TCP                                 137d
service-processei                        NodePort   <IP_ADDRESS>          80:9135/TCP                                  137d
==> v1/ServiceAccount
NAME                     SECRETS  AGE
processei-nginx-ingress  1        137d
==> v1beta1/ClusterRole
NAME                     AGE
processei-nginx-ingress  137d
==> v1beta1/ClusterRoleBinding
NAME                     AGE
processei-nginx-ingress  137d
==> v1beta1/Deployment
NAME                                     READY  UP-TO-DATE  AVAILABLE  AGE
processei-captcha                        1/1    1           1          137d
processei-cronos                         1/1    1           1          137d
processei-nginx-ingress-controller       1/1    1           1          137d
processei-nginx-ingress-default-backend  1/1    1           1          137d
processei-notifications-notifications    1/1    1           1          137d
processei-postgresql                     1/1    1           1          137d
processei-processei                      1/1    1           1          137d
processei-worker-api                     3/3    3           3          137d
==> v1beta1/PodDisruptionBudget
NAME                                     MIN AVAILABLE  MAX UNAVAILABLE  ALLOWED DISRUPTIONS  AGE
processei-nginx-ingress-controller       1              N/A              0                    137d
processei-nginx-ingress-default-backend  1              N/A              0                    137d
==> v1beta1/Role
NAME                     AGE
processei-nginx-ingress  137d
==> v1beta1/RoleBinding
NAME                     AGE
processei-nginx-ingress  137d
==> v1beta1/StatefulSet
NAME      READY  AGE
rabbitmq  1/1    137d
root@master:~# helm upgrade processei processei-1.1.tgz
UPGRADE FAILED
Error: kind Secret with the name "bounceruri" already exists in the cluster and wasn't defined in the previous release. Before upgrading, please either delete the resource from the cluster or remove it from the chart
root@master:~# helm upgrade processei processei-1.1.tgz  --reuse-values
UPGRADE FAILED
Error: kind Secret with the name "bounceruri" already exists in the cluster and wasn't defined in the previous release. Before upgrading, please either delete the resource from the cluster or remove it from the chart
Output of helm version: Client: &version.Version{SemVer:"v2.14.1", GitCommit:"5270352a09c7e8b6e8c9593002a73535276507c0", GitTreeState:"clean"}
Server: &version.Version{SemVer:"v2.14.1", GitCommit:"5270352a09c7e8b6e8c9593002a73535276507c0", GitTreeState:"clean"}
Output of kubectl version: Client Version: version.Info{Major:"1", Minor:"11", GitVersion:"v1.11.2", GitCommit:"bb9ffb1654d4a729bb4cec18ff088eacc153c239", GitTreeState:"clean", BuildDate:"2018-08-07T23:17:28Z", GoVersion:"go1.10.3", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"11", GitVersion:"v1.11.2", GitCommit:"bb9ffb1654d4a729bb4cec18ff088eacc153c239", GitTreeState:"clean", BuildDate:"2018-08-07T23:08:19Z", GoVersion:"go1.10.3", Compiler:"gc", Platform:"linux/amd64"}
Cloud Provider/Platform (AKS, GKE, Minikube etc.): self-hosted

Have you tried doing what the error suggests? What is the result?

@rafagonc Let me know if I am reiterating the issue correctly

you created a chart with some resources
installed the chart - release got created
added some resources to chart
upgraded the release - it worked
upgraded again - it failed

is that the case? if yes, I am not able reproduce it with 2.14.1

I have this problem specially when the chart has subcharts. My chart was installed on helm 2.12 I tried to update with 2.14, I did not want to but I will delete and install a brand new chart on 2.14 and try to update with 2.14.

When the installation occurs on 2.12 and upgrade on 2.14 it has the same bug, but when I installed using 2.14 the nexts updates was running fine.

That looks like a bug we don't want. I will try to reproduce this. I don't
think people should be deleting and reinstalling to just upgrade from 2.12
to 2.14 and use the new version without any issues
On Mon, Jun 17, 2019, 4:44 AM Rafael Gonçalves<EMAIL_ADDRESS>wrote:

Closed #5897 https://github.com/helm/helm/issues/5897.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/helm/helm/issues/5897?email_source=notifications&email_token=ADBXB2EEZYQ7G4ZML5PIIGLP23CNTA5CNFSM4HYNQ4A2YY3PNVWWK3TUL52HS4DFWZEXG43VMVCXMZLOORHG65DJMZUWGYLUNFXW5KTDN5WW2ZLOORPWSZGOSABVGLI#event-2416137005,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ADBXB2FLZPCN33VTUMKC2QLP23CNTANCNFSM4HYNQ4AQ
.

#3275

I've been getting this constantly on 2.13.1,   just upgraded to 2.14.1 and it seems to have gone away.

And I have it again, deployed everything worked fine, ran the EXACT same deployment, got the error.

@JasonCarter80 I had to helm delete my chart in the previous versions and install in 2.14, I know sometimes we cannot simply delete in production but it will resolve this issue.

I did that 2 days ago due to a MongoDB subchart and i upgraded to 2.14.2 and still the same.
What i noticed is it didn't start again until my revision count got quite high, so I removed and reinstalled Tiller with MAX_COUNT=10.
Another thing I've noticed is when i do helm history MYCHART, it throws an grpc error that:

helm history attachment-pro
Error: grpc: trying to send message larger than max (21178680 vs. 20971520)

But when I delete a few of the helm config maps for my chart, both my history, AND the deployment seemed to work.

I'm experiencing this bug as well.  I just rolled out 2.14 for my org to use, in the hopes I would have more bug fixes than bugs, but apparently I got unlucky this time.  Is anyone able to re-open this issue @rafagonc perhaps?

I fixed this problem by lowering my Tiller revision counts as @JasonCarter80 stated earlier. Now I can deploy the chart repeatedly without any issues. My guess is that there was some grpc communication issue causing this.

@rhefner1 Could you also post the value of the revision count you already had during the issue? Just in case we need to reproduce the issue, since there are many who have faced the issue

Also, if it's a tiller issue, with Helm 3 it will all go away for good. 😄

@karuppiah7890 I had 15 and I reduced it down to 3 and once I did a deployment, tiller deleted the old versions and then all subsequent deployments worked.

This problem remains for us even with max revision history at 10.
Helm version 2.14.3

This worked for me, but did you try helm rollback? I went all the way back to version 1.


If any Form JSON is malformed, we should present a warning to the user

We shouldn't silently do nothing. We need to actually show the user what's wrong


Address failing main -- trim some deps

[x] Address failing main by trimming some additional dependencies
[x] Add outputs to start_server in core testserver so we can see what went wrong when it fails to start

I'm quite unhappy that the venv prepend methodology isn't working as well as I'd hope on all python versions. Just seein some weirdness. Continuing to dig.

API change check
API changes are not detected in this pull request.

Adding a pyopenssl dependency to the dev_requirements.txt for azure-keyvault-certificates should resolve KV's CI failures.

Merging to unblock a release.


would you release the controlnet training code in the future?

The controlnet train codes on the Internet are all text to img. I have not found the control train code of img to img. Please tell me when this code will be made public. If it is not public, please tell me if there is any template code for reference. Thank you very much for your answer.

You can combine the text to img controlnet code with https://github.com/SUDO-AI-3D/zero123plus/issues/83#issuecomment-2161482394


array connection: add totalCount to Connection

The totalCount attribute on connection types makes it easy to get the
size of the entire collection and makes it explicit. This is especially
useful for large collections where calculating the total size can be
expensive. It's already passed in through the arguments anyway in meta,
but this makes sure it is exposed in the Connection object returned.
An example query:
{
  empire {
    ships {
      totalCount
    }
  }
}

While this is useful, I don't think we want to bake a notion of totalCount into the Relay connection spec. For some connections it is tractable to provide a count, but for others it is not (connections can also be effectively unlimited streams). That's why it's not in the spec.
So, in graphql-relay-js we want to stick with the minimum required fields laid out in the connection spec . If an application wishes to augment the connection with a count field, then it can do so (example below), but it should be baked in by default:
import {GraphQLInt} from 'graphql';
import {connectionDefinitions} from 'graphql-relay';
import TagType from '../../types/TagType';

const {connectionType: tagConnection} = connectionDefinitions({
  connectionFields: {
    count: {
      type: GraphQLInt,
      description: 'Total number of tags',
      resolve: connection => connection.count,
    },
  },
  name: 'Tag',
  nodeType: TagType,
});

export default tagConnection;

Feel free to comment here if you wish to discuss this further, @maletor. I'm going to mark it as closed for now to clear out the queue. Thanks for the PR!

This is good. I had not thought about infinite streams.


fix: Changelog script allows TODO entries

Checklist

[x] Commits are signed with Developer Certificate of Origin (DCO - learn more)

/skip-e2e


Doesn't work with the latest version of Next.js

Next uses a version 7 of babel and backpack uses version 6
This causes conflicts and one of the builds won't run.
Since backpack uses the same structure as next and doesn't allow you to specify a custom .babelrc file those have to be shared.
I managed to get this running by forking it and updating the dependencies.
But I'm still not sure that's the right solution so I won't open a PR.
It's a solution but not future proof. Def the best solution would be to be able to specify a .babelrc file in backpack.config.js other than the one on the root.

I've added nuxt js 2 and webpack 4 support here:
https://github.com/hokify-dev/backpack-core/commits/master
main changes:

ugprade to webpack 4
upgraded dependencies
removed json loader (webpack4 can do this itself now)

Fixed with 0.8


Implement platform-specific extensions

Hi PM from the VS Code team here 👋
See https://github.com/microsoft/vscode/issues/23251#issuecomment-918989339, VS Code Marketplace now allows extensions to publish different VSIXs for each specific platform. This should be very useful for LiveShare.
This document has all the details:
https://code.visualstudio.com/api/working-with-extensions/publishing-extension#platformspecific-extensions
fyi @davsterl

Please do not close this.

Closing as dup of https://github.com/MicrosoftDocs/live-share/issues/4781


Don't need atomic operations

Removing not needed code also benefits test coverage in another sense. #7


Drop crumb metadata to save breadcrumbs

Goal

Preserve breadcrumbs which would otherwise be dropped due to the size exceeding allowed limits
Remove the length limit on breadcrumb name values

These two are interconnected because breadcrumbs left via Bugsnag.leaveBreadcrumb(message) would no longer be able to be differentiated as all would have type = manual and name = manual.
Design
All breadcrumbs should now be sent, including a meaningful name.
               ┌─────────────────────┐
               │Can it be serialized │
           ┌───│      as JSON?       │────────┐
           │   └─────────────────────┘        │
      Yes! ▼                                  │ Nope
┌────────────────────┐                        │
│  Is it under 4kb?  │                        │
│                    │────────────────────────┤
└────────────────────┘                        ▼
           │            Nope       ┌────────────────────┐
     Yes!  │                       │Drop metadata, trim │
           │                       │    name to 4kb     │
           ▼                       └────────────────────┘
┌─────────────────────┐                       │
│  Send breadcrumb!   │◀──────────────────────┘
└─────────────────────┘

This should be closed as the notifier spec no longer mandates that breadcrumbs should be trimmed on size alone, as users have found this confusing.


[LTO] Support LLVM LTO for driver

This commit adds LTO support for handling linker options and LLVM BC
emission. Even for ELF, swift-autolink-extract is unnecessary because
linker options are embedded in LLVM BC content when LTO.
This is pulled out from https://github.com/apple/swift/pull/32237 and based on https://github.com/apple/swift/pull/32429

Replace this paragraph with a description of your changes and rationale. Provide links to external references/discussions if appropriate.

Resolves SR-NNNN.

@compnerd @gottesmm Could you review this?

I am not a driver person so I am asking around for a driver person to look at this.

@brentdax

In addition to the inline comments, please take a look at validateEmbedBitcode() and think about whether file_types::TY_LLVM_BC ought to now be valid there.

When LTO, frontend always emit bitcode, so ignoring bitcode embedding is expected behavior. Thanks for letting me know that case.

Could you trigger CI for all platforms?

@swift-ci please test

Build failed
Swift Test Linux Platform
Git Sha - a27e31636a3bae8778752e405359c4c69b63ddc3

Build failed
Swift Test OS X Platform
Git Sha - a27e31636a3bae8778752e405359c4c69b63ddc3

@swift-ci please test Windows platform

Hmm, the window CI failed due to a broken zipfile. I think it's worth triggering again.
ci@SWIFTCI-WINDOWS S:\jenkins\workspace\swift-PR-windows>"C:\Program Files\Git\usr\bin\unzip.exe" -o icu4c-64_2-Win64-MSVC2017.zip -d "S:\jenkins\workspace\swift-PR-windows\icu-64_2"
Archive:  icu4c-64_2-Win64-MSVC2017.zip
  End-of-central-directory signature not found.  Either this file is not
  a zipfile, or it constitutes one disk of a multi-part archive.  In the
  latter case the central directory and zipfile comment will be found on
  the last disk(s) of this archive.
unzip:  cannot find zipfile directory in one of icu4c-64_2-Win64-MSVC2017.zip or
        icu4c-64_2-Win64-MSVC2017.zip.zip, and cannot find icu4c-64_2-Win64-MSVC2017.zip.ZIP, period.

@swift-ci please test Windows platform

@swift-ci please test Windows platform

@swift-ci please test

Build failed
Swift Test Linux Platform
Git Sha - 936f379ff7c260624b23f5ef5367313b91eea5e5

Build failed
Swift Test OS X Platform
Git Sha - 936f379ff7c260624b23f5ef5367313b91eea5e5

Would reviews from anyone else be needed before this can be merged?

@brentdax Thanks for review again. I addressed commented points.
And thank you @MaxDesiatov for facilitating review.

@swift-ci please test

Build failed
Swift Test OS X Platform
Git Sha - af3ee5084d7fa088f759b386a4ab535368a32a76

Build failed
Swift Test Linux Platform
Git Sha - af3ee5084d7fa088f759b386a4ab535368a32a76

@swift-ci please test Windows platform

@swift-ci please test

@swift-ci please test Windows platform

@compnerd thanks for the review. Would you mind having another look?

@brentdax @compnerd @gottesmm Would you mind taking a look again?

@compnerd @gottesmm would you have a moment to have a look at this PR? Thank you!


Fixes of Schema.org and Microformats data.

To test structured data see
Google Structured Data Tool.
To test W3C syntax see W3 Html Checker.
To see all changes and results see that article.

After all fixes and improvements i have this and this result.

Thanks. :+1:


Cannot create ldapServer ressource

Hi,  i cannot update the ressource "ldapServer" 👍

{resource_type: "ldapServer", authority: "XXX", binDN: "CN=XXX,OU=utilisateur,OU=XXX,OU=XXX,DC=XXX,DC=XXX,DC=XX,DC=XX", bindPassword: "XXX", userSearchPath: "OU=Utilisateur,DC=XX,DC=XX,DC=XX,DC=XX", groupSearchPath: "DC=XX,DC=XX,DC=XX,DC=XX"}

THE ERROR IS:
"error": {
"errorCode": 131149877,
"httpStatusCode": 422,
"messages": [
{
"en-US": "Request body is not correct. There may be duplicate parameters, wrong parameter name. Please refer to API documentation page and ensure the body is correct. (Error Code:0x7d13035)"
}
],
"created": "2019-08-20T18:34:05.853Z"
}
}
}
Any idea what wrong ?
thanks
Dominic

@dapiced, Have you tried to send the same request via any REST client?
If you ask about Unity REST API, it will take a time to find solution, because, unfortunately, now I haven't any Unity (Unity VSA). I am going to deploy it on September.

yes,  i try with postman, but for some reason, im not able to login with postman

You should use csrf token and basic auth both. You can get csrf token by sending any GET request with basic auth authorization

i tried with basic auth, but  Unity return to me with the "user/login page"
i also try bearer auth without succes

I finally been able to login with csrf token, but still having a error
{
"error": {
"errorCode": 131150096,
"httpStatusCode": 400,
"messages": [
{
"en-US": "Invalid request argument: [authority]. (Error Code:0x7d13110)"
}
],
"created": "2019-08-20T20:11:41.053Z"
}
}

finaly it was a typo !
binDN:  instead of bindDN:


Add signing capabilities

Is your feature request related to a problem? Please describe.
Maybe it will be a great feature to have an opportunity to add signatures to data stored in the database. So, it will be possible to verify integrity of data stored in the database on the client side. It can be used to determine if there were changes of the signed data.
Describe the solution you'd like
Add a new structure called SignedValue which will use SignatureAlgorithms variable and as EncryptedValue use the first algorithm to sign data and use other algorithms with lower priority (fallbacks) if it's not possible to verify signature with the first (primary) algorithm. Example SignedValue struct based on EncryptedValue:
type SignedValue struct {
    Raw   interface{} `json:"Raw"`
    Valid bool        `json:"Valid"`
}

Raw is value which is stored in the database, Valid is boolean which tells if the Raw value is signed correctly.

@pkosilo, I'd like to work on it myself

@pkosilo, I'd like to work on it myself

@pkosilo, I'd like to work on it myself

Okay 👍

@pkosilo, I'd like to work on it myself

Okay 👍


panic: runtime error: slice bounds out of range in lumberjack.go:269

Hi,
After about 20-ish hours of working my application crashes with the following panic() in lumberjack.
Could there be some kind of out of order condition that could cause files[] to panic?
Using version:
                    "ImportPath": "github.com/natefinch/lumberjack",
                    "Comment": "v1.0-2-ga6f35ba",
                    "Rev": "a6f35bab25c9df007f78aa90c441922062451979"

panic: runtime error: slice bounds out of range
goroutine 61 [running]:
github.com/natefinch/lumberjack.(*Logger).cleanup(0xc208082d20, 0x0, 0x0)
	/obfuscated/Godeps/_workspace/src/github.com/natefinch/lumberjack/lumberjack.go:269 +0x513
github.com/natefinch/lumberjack.(*Logger).rotate(0xc208082d20, 0x0, 0x0)
	/obfuscated/Godeps/_workspace/src/github.com/natefinch/lumberjack/lumberjack.go:179 +0xb0
github.com/natefinch/lumberjack.(*Logger).Write(0xc208082d20, 0xc208e45900, 0x1cf, 0x247, 0x0, 0x0, 0x0)
	/obfuscated/Godeps/_workspace/src/github.com/natefinch/lumberjack/lumberjack.go:131 +0x316
bytes.(*Buffer).WriteTo(0xc20b172e00, 0x7f5f3f4a57e0, 0xc208082d20, 0x0, 0x0, 0x0)
	/usr/src/go/src/bytes/buffer.go:202 +0xda
io.Copy(0x7f5f3f4a57e0, 0xc208082d20, 0x7f5f3f4a5790, 0xc20b172e00, 0x0, 0x0, 0x0)
	/usr/src/go/src/io/io.go:354 +0xb2
github.com/Sirupsen/logrus.(*Entry).log(0xc2097d4140, 0x4, 0xc209018030, 0x2c)
	/obfuscated/Godeps/_workspace/src/github.com/Sirupsen/logrus/entry.go:94 +0x4d1
github.com/Sirupsen/logrus.(*Entry).Info(0xc2097d4140, 0xc217d53ba8, 0x1, 0x1)
	/obfuscated/Godeps/_workspace/src/github.com/Sirupsen/logrus/entry.go:119 +0x7f

This looks like this area of code for me:
	if l.MaxBackups > 0 {
		deletes = files[l.MaxBackups:]
		files = files[:l.MaxBackups]
	}

Thanks for the bug report.  I'm traveling today but will take a look at it tomorrow.

It looks like you're using lumberjack v1.  I would recommend switching to lumberjack v2. (gopkg.in/natefinch/lumberjack.v2). I made several improvements, and it's currently in production use in a large number of installations as a part of Juju (jujucharms.com). I'll look at this panic, but I wouldn't recommend using v1 if you have the option. It's deprecated in favor of v2.

Hi,
Thanks for looking into this.
I'm developing off of the master branch and using godep to manage the dependencies of my binary.  Most open source golang projects release the latest version of their code on the master branch.
  The behavior most consistent with the golang community would be to have the latest version of your code on the master branch and save tags for people that want a specific API.  Deprecating the master branch could lead to confusion for people using go get on this github repository.
Rather than deprecated it, why not remove or rename it to prevent any confusion?

Agree with @cep21

You can use go get to get the v2 branch of this code by simply doing go get gopkg.in/natefinch/lumberjack.v2.   Using gopkg.in to control versioning of repos is fairly common practice, or at least not uncommon.
I could, in theory, break or remove the master branch so that no one can use it, but that doesn't seem very user friendly.  I put a deprecation warning in the readme for the master branch... unfortunately there's no way to emit a warning when you compile, other than to actually break the code and stop it from compiling, which I don't really want to do (and which wouldn't work if you're pinning the revision using godep anyway).


Add a try_with method to LocalKey

Rendered
You probably know LocalKey as being the creation of the thread_local! macro.
This is my first RFC, so let me know if I'm doing anything wrong.

Is it normal for an RFC to go this long without comments? Is there something I can do to help the process?

I think having a try_with method would be useful to some, but I'm not sure how often the existing with method causes problems. It is true that the current situation requires checking twice, but if state is removed, using try_with(|| {}).is_ok() isn't pretty either. Because of this, I think state should stay, but as I said, these situations may not be uncommon, so hopefully someone that uses this feature has better feedback.

Another thing I didn't previously consider about the state is that it's thread local, so if you check state a with call is guaranteed to succeed. I'll change the RFC to not deprecate state. There's also not much reason to deprecate state, so I'll stay on the side of ensuring usability.

It's been another two weeks since a comment - bump again. Should I continue bumping this, or is there just no interest in this? I'd do the implementation.

The process description has this bullet point:

Each pull request will be labeled with the most relevant sub-team, which will lead to its being triaged by that team in a future meeting and assigned to a member of the subteam.

The first part of this has happened but the second has not (and it should, for every RFC). I'm not sure if they're just busy and haven't gotten to it, or if they accidentally overlooked the RFC. In any case I hope they don't mind if I ping them about it: @brson @alexcrichton @sfackler @BurntSushi @Kimundi @dtolnay @aturon [as far as I'm aware I can't ping @rust-lang/libs directly because I'm not on a team myself]

Thanks for the RFC @PlasmaPower but I'm not sure that this will satisfy all current use cases for the state method. Right now different locations will act differently depending on the state returned from that function, whereas I believe the proposed semantics here would fold the Valid and Uninitialized states together. It seems reasonable to me to add a function to more gracefully handle the Destroyed state but I don't think we'll be able to deprecate state yet.

@alexcrichton The RFC as it stands doesn't deprecate state. While I still haven't found a use case for state, I see why there might be one, so the RFC currently keeps it as is.

If that's the case then this probably doesn't need an RFC and can likely just be a PR. If you'd like you can close this an submit a PR to rust-lang/rust.

I was wondering about that! The readme did say additions to std needed an rfc, but I guess this is pretty small. I'll just wrap it into the existing state feature I guess.


Debugger support change for 8.0

Description
@maraf ... The section was added on #32287 ...
https://github.com/dotnet/AspNetCore.Docs/pull/32287/files
That's only spot where the article discusses the app's debug, release, or custom configuration.
Do we need to keep that section because a dev will still need to set <DebuggerSupport> for non-Debug/non-Release custom configs? If that's the change, we keep the section but change one line.
From ...

By default, the Blazor framework *disables* debugger support for all non-Debug configurations. To enable debugger support for a non-Debug configuration, add a `<DebuggerSupport>` property to the app's project file.

... to ...

By default, the Blazor framework *disables* debugger support for all non-Debug/non-Release custom configurations. To enable debugger support for a custom configuration, add a `<DebuggerSupport>` property to the app's project file.

While I'm at it, I'll also remove 🔪 the "For more information" line.
Alternatively if the configuration is irrelevant now, then I just need to 🔪 the entire section out of the doc.
Page URL
https://learn.microsoft.com/en-us/aspnet/core/blazor/debug?view=aspnetcore-8.0&tabs=visual-studio
Content source URL
https://github.com/dotnet/AspNetCore.Docs/blob/main/aspnetcore/blazor/debug.md
Document ID
4d06e565-282d-6387-aa90-cb2c2986d35a
Article author
@guardrex

Do we need to keep that section because a dev will still need to set  for non-Debug/non-Release custom configs?

No, we should remove DebuggerSupport as that won't be needed anymore

Very well ... I'll take care of it within a few hours. I'm buried in Blazor Hybrid code at the moment. ⛰⛏😅

No rush, the fix not released yet


Adds some LWRPs for managing exchanges

Uses the REST api to add and remove Exchanges and Exchange Bindings.

@hufman Is there anything holding this up?

I'm sorry, I haven't had time to work on this since then, my job has called me away to other things.

I can try to clean this up if we think it is still a good approach. cc @michaelklishin @jjasghar

Closing due to inactivity, opened issue #251 as a placeholder to refactor this with the https://github.com/ruby-amqp/rabbitmq_http_api_client


Can't remove all entries of the tags/list field

Describe the issue that you're seeing. Any Loom videos or screenshots usually help a lot!
As per the documentation , when a field is omitted , it would get deleted.
However i have a jekyll blog post with tags, I used the tags ui component. I am able to add/update more tags to a post. I can also remove an existing tag.
However when i  remove the last tag and hit save, I notice in the browser network tab , that field is omitted in the graphql update mutation. As per tina cms documentation , "Omitting a field will result in it being nullified."
However I am not able to remove the last tag from the post. Very sure there is nothing wrong with the config , because i am using the exact same config as the documentation and like i said i am able to add , remove tags . The problem is with just not being able to remove the very last tag.
https://github.com/tinacms/tinacms/assets/1474415/6cf0aa25-5c52-4c92-8404-fe821fdb12ad
Reproduction
https://mythoughtsto.day/
Steps to reproduce
In the above screenshot , I am using a custom tag UI component , however I have also tried using the tag component provided by Tina and used the exact same config as provided in the documentation.
System Info
System:
    OS: macOS 13.4.1
    CPU: (10) arm64 Apple M1 Max
    Memory: 303.06 MB / 32.00 GB
    Shell: 5.9 - /bin/zsh
  Binaries:
    Node: 16.17.0 - ~/.nvm/versions/node/v16.17.0/bin/node
    Yarn: 3.6.0 - ~/code/annoblog/node_modules/.bin/yarn
    npm: 8.15.0 - ~/.nvm/versions/node/v16.17.0/bin/npm
  Browsers:
    Chrome: 114.0.5735.198
    Safari: 16.5.1
  npmPackages:
    @tinacms/cli: ^1.5.6 => 1.5.22
    tinacms: ^1.4.6 => 1.5.13

Validations

[X] Follow our Code of Conduct
[X] Read the docs.
[X] Check that there isn't already an issue that reports the same bug.

I believe this is now fixed. In the duplicate issue, I'm no longer able to reproduce with the reproduction repo. If you still are running into it on the latest Tina version, let us know


Customer feedback & build error | stack-hci-vm | broken links in azure-cli-extensions-list.md

Describe the bug
Feedback category
Broken links
Document URL:
https://learn.microsoft.com/en-us/cli/azure/azure-cli-extensions-list
Broken links

Extension link: https://github.com/Azure/azure-cli-extensions/tree/master/src/stack-hci-vm
Release notes link: https://github.com/Azure/azure-cli-extensions/tree/master/src/stack-hci-vm

Reference command
stack-hci-vm extension
Summary
From Learn Customer Feedback and azure-docs-cli build report, the stack-hci-vm links in the Extension list table return a 404.
Customer feedback
"
stack-hci-vm extension link is broken.
"
Screen print on 2024-06-27

Related command
az stack-hci
Reference page:
https://learn.microsoft.com/en-us/cli/azure/stack-hci
Errors
404
Issue script & Debug output
n/a
Expected behavior
n/a
Environment Summary
n/a
Additional context
No response

Thank you for opening this issue, we will look into it.

Duplicate GitHub issue.  See #29501


Implement UART transmit functionality.

Need to reuse it for:

transmit to radio board at 1200baud
transmit to telemetry board at 2x-3x speed of incoming GPS messages (please note that not all incoming GPS messages will be transmitted to telemetry board).

done


[json-schema-loader] Breaks Webpack 2

As per the most recent commit - https://github.com/cloudflare/json-schema-loader/commit/2e75f223a77c987b66e98d054c3018d3e64f93dc - this now breaks for webpack 2.
The docs specify that callback should be invoked with a second argument that looks like a sourcemap, not an arbitrary type. https://webpack.js.org/api/loaders/#this-callback.
We are able to use 0.0.3 and it works, but you might want to specify webpack version in the readme.

This will also need an update to json-schema-example-loader to consume the different argument.

@tajo reading up on this I'm questioning whether json-schema-loader is what we need in the doca suite.  Per https://webpack.js.org/api/loaders/, loaders transform source code to source code (where JSON is the source "code" in question).
We're not actually doing that anymore: we're transforming source code to in-memory JavaScript data structures, and that is what we need in order to handle circular references and fully support the JSON Schema spec.
Bundling the loaded schemas, as suggested in json-schema-loader#3, would work and be of value by producing a self-contained JSON Schema for each schema file that defines endpoints.  But for json-schema-example-loader, we would just have to call dereference on it to get it into the in-memory structure, so it wouldn't really give us anything.  In that case we could drop json-schema-loader and it would behave identically.
So while I can definitely see a use for json-schema-loader, I'm not sure it's serving our needs in doca.  I know loaders are each supposed to do one thing, but I can't think of a way to do a source-to-source transformation with circular references that is useful for us.  Can you?

@wmonk if we decide we don't need json-schema-loader in the doca suite, we would still likely fix it for webpack 2 and keep it as an active project, we'd just change it to be standalone and give it its own issues list, etc.

I think this is what I want to do (folding in the bundle idea from cloudflare/json-schema-loader#3 )

Add a parameter that allows using bundle instead of dereference
When dereferencing, catch the error from a circular reference and print a message advising the bundle option
Only output JSON, in order to be compliant with webpack 2 (json-schema-example-loader will stay on the current version for now)

json-schema-loader has been deprecated in favor of the new @cloudflare/json-schema-ref-loader in the https://github.com/cloudflare/json-schema-tools repository.  @cloudflare/json-schema-ref-loader does not use the extra parameter.  The requested bundling feature is tracked as cloudflare/json-schema-tools#2


Fix unstable mod tidy

Fix #1326
Signed-off-by: Megrez Lu<EMAIL_ADDRESS>

Looks good, but can you find a way to provide a positive confirmation that this is indeed the version being included? Running go mod graph | grep dns shows all versions that our dependencies use for this, so, it wouldn't help much I think...

After some investigation, I find that "github.com/miekg/dns" module does not exist in the binary built with make gobuild at all. So I think it is safe to run go mod tidy to make a cleanup.
I have tested with both objdump and go tool objdump.

Sounds good to me. We might want to get an approval from @objectiser as well, as it was introduced by him some time ago.

The second commit, where the dependency is listed in the replace section, seemed ok - but without that it reverts the version of the dependency which is affected by the CVE. What was the issue with the second commit?

The second commit, where the dependency is listed in the replace section, seemed ok - but without that it reverts the version of the dependency which is affected by the CVE. What was the issue with the second commit?

The affected module "github.com/miekg/dns" seems not appear in the generated binary. So I suppose it is safe to run go mod tidy here.


modeling_create_smoment_model cannot handle 'NoneType' objects

Hello,
This might be a bit early to report an issue, however I am really interested in the construction of an enzyme constrained model for yeast using autopacmen. Even though I am not very familiar with the python environment, I was able to follow your manual up to some point  (thank you for the clear explanations!), unfortunately I've encountered several small errors that you might want to fix since you consider the autopacmen as an extension for cobrapy:
(skip bullets for the main question)

All scripts with data_parse_ in their names  (except data_parse_bigg_metabolites_file) require an output file to be in the path beforehand. They overwrite the file, but throw an error about the path if file is not there in the first place.
In the manual, part usage: data_parse_brenda_textfile.py example uses a different script data_parse_bigg_metabolites_file. This is probably a copy/paste typo.
The argument type_of_kcat_selection is missing in the function get_reactions_kcat_mapping() in the script modeling_get_reactions_kcat_mapping. I was able to add the parameter and continue without a problem.
data_create_combined_kcat_database asks for a "BRENDA path" input instead of an "output path" if you run the python script without parameters in the terminal.
Similar to previous one, modeling_create_smoment_model,  asks an input for "SBML name" for a second time, instead of "excluded reactions".

This was the point that I could not continue further because I got several errors in modeling_create_smoment_model. As you can see from the title, it throws an error for my model:
File "~/autopacmen/autopacmen/submodules/helper_general.py", line 243, in get_float_cell_value
    cell_value = cell_value.replace(",", ".")
AttributeError: 'NoneType' object has no attribute 'replace'

I have obtained this error using Python 3.7.5 on Linux (Ubuntu 18.04.4 LTS). I have tried to modify get_float_cell_value to bypass replace for NoneType objects, unfortunately my solutions failed in the downstream (mostly in the function add_prot_pool_reaction). As I mentioned before, I am not good at Python programming, so my solutions can be considered weak. There are several metabolites and enzymes in my model that no information available in the databases (retrival scripts showed NA's and warnings for them). I believe these should not cause a problem, therefore I am asking for a solution.
Sorry if I am not clear or went wrong. I hope these small problems I reported above help you to enhance autopacmen and you can provide a generalized solution for my problem soon.
Thank you in advance,
Handan

Hello Handan \o/
Thank you for reporting the helpful issue :D
Regarding the minor bullet point issues:

The data_parse_ scripts should only throw an error if the given output file path contains a non-existing folder (please correct me if the scripts show a different behavior). I just didn't think of mentioning it as it is typical Python file operation behavior, and I just added the information to the manual.
That's indeed a typo, I corrected it in the manual and the associated code documentation.
That's indeed a mistake in the code, I added the corresponding argument.
& 5. I just corrected these typos in the code, too.

All these changes can be found in today's new autopacmen release.
Regarding the major issue:
The error arises when at least one value in missing in one of the given model-associated XLSX files. In order to see where the error occurs, it would be helpful if you could report the full error stack trace, i.e. all other error lines before the one that you included in the issue.
Kind regards :-)
P.S.B.

Closing due to inactivity and since the remaining issue was probably related to an already fixed faulty generation of initial spreadsheets.


Logging with Invalid Handle

Update logging to handle cases where client does not have a valid handle. This happens when the application DI container is setup via AddKafkaClient and the dictionary contains both consumer and producer configuration values. When constructing a Consumer, the underlying kafka library logs encountering a producer configuration value. Same thing occurs when constructing a Producer, regarding consumer configuration values.

Makes sense, thanks :)

IMO this should also be addressed in Confluent.Kafka: https://github.com/confluentinc/confluent-kafka-dotnet/issues/1994


remove stray brace in readme

no need to thank me i very humble about my giant massive contribution to this project


Added FakeClient stub for testing

Not passing, will test on Python 3.4 and 3.5 before merging to master


add geo coding component

add a geocoding component to get addresses with auto-complete search and get the selected area at maps

Hi Randa,
Thank you for the contribution and sorry for the late response. I just returned from vacation and my colleagues and I are currently busy with project work. But I will look into it soon and am looking forward to test this component and get it incorporated into the module.

No worries at all! I hope you had a fantastic vacation. We all get busy, so there's no rush on this.
I'm looking forward to testing out the component whenever things go better. Thanks again for your response!


[ASTImporter] Fix IsStructuralMatch specialization for EnumDecl to prevent re-importing an EnumDecl while trying to complete it

Summary:
We may try and re-import an EnumDecl while trying to complete it in IsStructuralMatch(...) specialization for EnumDecl. This change mirrors a similar fix for the specialization for RecordDecl.
Differential Revision: https://reviews.llvm.org/D59845
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@357100 91177308-0d34-0410-b5e6-96231b3b80d8
(cherry picked from commit 1c1e6801d6e32a7cdba32a7865efa6b7027cbecb)

@swift-ci test


function that cleans up blob container

Files after being processed are moved to archive

[ ] create a function that cleans up certdata and certservice blob

Have ProcessCertDataFile and ProcessCertServiceFile functions archive then delete instead of seperate functions

https://github.com/learntocloud/azure-project-generator/pull/21


Code is difficult to reproduce

Hello, which version of tensorflow and torch are you using? I used torch1.13.0+tensorflow2.5+cuda11.2 and got an error: "FileNotFoundError: Op type not registered 'DisableCopyOnRead' in binary runn", and the model could not be loaded. After changing to tensorflow2.13.0, an error still occurred:
tensorflow.python.framework.errors_impl.UnimplementedError: Graph execution error:
Detected at node 'superpoint/pred_tower0/vgg/conv1_1/conv/Relu' defined at (most recent call last):
Node: 'superpoint/pred_tower0/vgg/conv1_1/conv/Relu'
Detected at node 'superpoint/pred_tower0/vgg/conv1_1/conv/Relu' defined at (most recent call last):
Node: 'superpoint/pred_tower0/vgg/conv1_1/conv/Relu'
2 root error(s) found.
(0) UNIMPLEMENTED: DNN library is not found.
[[{{node superpoint/pred_tower0/vgg/conv1_1/conv/Relu}}]]
[[superpoint/descriptors/_157]]
(1) UNIMPLEMENTED: DNN library is not found.
[[{{node superpoint/pred_tower0/vgg/conv1_1/conv/Relu}}]]
0 successful operations.
0 derived errors ignored.
Original stack trace for 'superpoint/pred_tower0/vgg/conv1_1/conv/Relu':
How can I solve this problem? Thank you!

I’ve got a same problem

I‘ve also encountered this problem

I also encountered this problem

@ZXW-King I got the same problem, did you solve it


change the rsyslog configuration file

change this file  security-config-omsagent.confto contain this:
:rawmsg, regex, "CEF"|"ASA"
. @@<IP_ADDRESS>:25226
Instead of this:
        :rawmsg, regex, "CEF\|ASA" ~
        *.* @@<IP_ADDRESS>:25226

@morshabi : Thanks for your contribution! The author(s) have been notified to review your proposed change.

#sign-off


High Rate of Deadline Exceeded and Internal Error

Overnight we started seeing an elevated rate of DEADLINE_EXCEEDED errors when querying SearchStream and now we're seeing an extremely high rate of "Internal error occurred"
./deadline-exceeded-test.sh
/efs/api/google/requests/new-google-requests-summary.2022-09-06.log 103
/efs/api/google/requests/new-google-requests-summary.2022-09-07.log 155
/efs/api/google/requests/new-google-requests-summary.2022-09-08.log 649

./internal-error-test.sh
/efs/api/google/requests/new-google-requests-summary.2022-09-06.log 67
/efs/api/google/requests/new-google-requests-summary.2022-09-07.log 449
/efs/api/google/requests/new-google-requests-summary.2022-09-08.log 10579

traceroute to googleads.googleapis.com (<IP_ADDRESS>), 50 hops max, 60 byte packets
 1  ip-172-31-67-206.us-east-2.compute.internal (<IP_ADDRESS>)  0.126 ms  0.108 ms  0.101 ms
 2  ec2-52-15-0-41.us-east-2.compute.amazonaws.com (<IP_ADDRESS>)  7.318 ms ec2-52-15-0-53.us-east-2.compute.amazonaws.com (<IP_ADDRESS>)  6.556 ms ec2-52-15-0-45.us-east-2.compute.amazonaws.com (<IP_ADDRESS>)  8.382 ms
 3  <IP_ADDRESS> (<IP_ADDRESS>)  0.954 ms <IP_ADDRESS> (<IP_ADDRESS>)  4.780 ms <IP_ADDRESS> (<IP_ADDRESS>)  2.218 ms
 4  <IP_ADDRESS> (<IP_ADDRESS>)  3.368 ms <IP_ADDRESS> (<IP_ADDRESS>)  3.799 ms <IP_ADDRESS> (<IP_ADDRESS>)  7.478 ms
 5  <IP_ADDRESS> (<IP_ADDRESS>)  15.989 ms <IP_ADDRESS> (<IP_ADDRESS>)  19.229 ms  19.202 ms
 6  <IP_ADDRESS> (<IP_ADDRESS>)  0.794 ms <IP_ADDRESS> (<IP_ADDRESS>)  0.784 ms <IP_ADDRESS> (<IP_ADDRESS>)  0.940 ms
 7  <IP_ADDRESS> (<IP_ADDRESS>)  0.827 ms <IP_ADDRESS> (<IP_ADDRESS>)  1.195 ms <IP_ADDRESS> (<IP_ADDRESS>)  0.924 ms
 8  <IP_ADDRESS> (<IP_ADDRESS>)  1.776 ms <IP_ADDRESS> (<IP_ADDRESS>)  1.703 ms <IP_ADDRESS> (<IP_ADDRESS>)  0.815 ms
 9  <IP_ADDRESS> (<IP_ADDRESS>)  2.959 ms <IP_ADDRESS> (<IP_ADDRESS>)  2.780 ms <IP_ADDRESS> (<IP_ADDRESS>)  1.755 ms
10  <IP_ADDRESS> (<IP_ADDRESS>)  3.191 ms <IP_ADDRESS> (<IP_ADDRESS>)  5.407 ms <IP_ADDRESS> (<IP_ADDRESS>)  2.583 ms
11  <IP_ADDRESS> (<IP_ADDRESS>)  3.242 ms <IP_ADDRESS> (<IP_ADDRESS>)  2.182 ms <IP_ADDRESS> (<IP_ADDRESS>)  9.112 ms
12  <IP_ADDRESS> (<IP_ADDRESS>)  12.156 ms <IP_ADDRESS> (<IP_ADDRESS>)  11.912 ms <IP_ADDRESS> (<IP_ADDRESS>)  11.722 ms
13  <IP_ADDRESS> (<IP_ADDRESS>)  12.143 ms <IP_ADDRESS> (<IP_ADDRESS>)  12.232 ms <IP_ADDRESS> (<IP_ADDRESS>)  12.238 ms
14  <IP_ADDRESS> (<IP_ADDRESS>)  12.156 ms <IP_ADDRESS> (<IP_ADDRESS>)  12.335 ms <IP_ADDRESS> (<IP_ADDRESS>)  12.311 ms
15  <IP_ADDRESS> (<IP_ADDRESS>)  14.644 ms <IP_ADDRESS> (<IP_ADDRESS>)  12.759 ms <IP_ADDRESS> (<IP_ADDRESS>)  12.204 ms
16  <IP_ADDRESS> (<IP_ADDRESS>)  13.322 ms <IP_ADDRESS> (<IP_ADDRESS>)  12.066 ms <IP_ADDRESS> (<IP_ADDRESS>)  11.927 ms
17  <IP_ADDRESS> (<IP_ADDRESS>)  13.970 ms  13.962 ms <IP_ADDRESS> (<IP_ADDRESS>)  12.113 ms
18  * <IP_ADDRESS> (<IP_ADDRESS>)  12.543 ms *
19  <IP_ADDRESS> (<IP_ADDRESS>)  12.394 ms * <IP_ADDRESS> (<IP_ADDRESS>)  12.203 ms
20  <IP_ADDRESS> (<IP_ADDRESS>)  12.703 ms <IP_ADDRESS> (<IP_ADDRESS>)  12.628 ms <IP_ADDRESS> (<IP_ADDRESS>)  12.705 ms
21  <IP_ADDRESS> (<IP_ADDRESS>)  13.374 ms <IP_ADDRESS> (<IP_ADDRESS>)  14.782 ms *
22  <IP_ADDRESS> (<IP_ADDRESS>)  18.029 ms * <IP_ADDRESS> (<IP_ADDRESS>)  13.271 ms
23  <IP_ADDRESS> (<IP_ADDRESS>)  18.219 ms <IP_ADDRESS> (<IP_ADDRESS>)  19.809 ms *
24  <IP_ADDRESS> (<IP_ADDRESS>)  18.715 ms <IP_ADDRESS> (<IP_ADDRESS>)  18.388 ms <IP_ADDRESS> (<IP_ADDRESS>)  19.304 ms
25  ord38s42-in-f10.1e100.net (<IP_ADDRESS>)  18.513 ms <IP_ADDRESS> (<IP_ADDRESS>)  20.021 ms mia09s16-in-f10.1e100.net (<IP_ADDRESS>)  18.654 ms

Request
-------
MethodName: google.ads.googleads.v11.services.GoogleAdsService/SearchStream
Endpoint: googleads.googleapis.com:443
Headers: {developer-token=REDACTED, login-customer-id=5864512560, x-goog-api-client=gl-java/11.0.15 gccl/21.0.0 gapic/21.0.0 gax/2.16.0 grpc/1.45.1 pb/3.19.4}
Body: customer_id: "9292695725"
query: "select accessible_bidding_strategy.id, accessible_bidding_strategy.maximize_conversion_value.target_roas, accessible_bidding_strategy.maximize_conversions.target_cpa_micros, accessible_bidding_strategy.name, accessible_bidding_strategy.owner_customer_id, accessible_bidding_strategy.owner_descriptive_name, accessible_bidding_strategy.resource_name, accessible_bidding_strategy.target_cpa.target_cpa_micros, accessible_bidding_strategy.target_impression_share.cpc_bid_ceiling_micros, accessible_bidding_strategy.target_impression_share.location, accessible_bidding_strategy.target_impression_share.location_fraction_micros, accessible_bidding_strategy.target_roas.target_roas, accessible_bidding_strategy.target_spend.cpc_bid_ceiling_micros, accessible_bidding_strategy.target_spend.target_spend_micros, accessible_bidding_strategy.type, bidding_strategy.currency_code, bidding_strategy.effective_currency_code, bidding_strategy.enhanced_cpc, bidding_strategy.id, bidding_strategy.maximize_conversion_value.cpc_bid_ceiling_micros, bidding_strategy.maximize_conversion_value.cpc_bid_floor_micros, bidding_strategy.maximize_conversion_value.target_roas, bidding_strategy.maximize_conversions.cpc_bid_ceiling_micros, bidding_strategy.maximize_conversions.cpc_bid_floor_micros, bidding_strategy.maximize_conversions.target_cpa_micros, bidding_strategy.name, bidding_strategy.resource_name, bidding_strategy.status, bidding_strategy.target_cpa.cpc_bid_ceiling_micros, bidding_strategy.target_cpa.cpc_bid_floor_micros, bidding_strategy.target_cpa.target_cpa_micros, bidding_strategy.target_impression_share.cpc_bid_ceiling_micros, bidding_strategy.target_impression_share.location, bidding_strategy.target_impression_share.location_fraction_micros, bidding_strategy.target_roas.cpc_bid_ceiling_micros, bidding_strategy.target_roas.cpc_bid_floor_micros, bidding_strategy.target_roas.target_roas, bidding_strategy.target_spend.cpc_bid_ceiling_micros, bidding_strategy.target_spend.target_spend_micros, bidding_strategy.type, campaign.accessible_bidding_strategy, campaign.ad_serving_optimization_status, campaign.advertising_channel_sub_type, campaign.advertising_channel_type, campaign.app_campaign_setting.app_id, campaign.app_campaign_setting.app_store, campaign.app_campaign_setting.bidding_strategy_goal_type, campaign.audience_setting.use_audience_grouped, campaign.base_campaign, campaign.bidding_strategy, campaign.bidding_strategy_system_status, campaign.bidding_strategy_type, campaign.campaign_budget, campaign.campaign_group, campaign.commission.commission_rate_micros, campaign.dynamic_search_ads_setting.domain_name, campaign.dynamic_search_ads_setting.feeds, campaign.dynamic_search_ads_setting.language_code, campaign.dynamic_search_ads_setting.use_supplied_urls_only, campaign.end_date, campaign.excluded_parent_asset_field_types, campaign.experiment_type, campaign.final_url_suffix, campaign.frequency_caps, campaign.geo_target_type_setting.negative_geo_target_type, campaign.geo_target_type_setting.positive_geo_target_type, campaign.hotel_setting.hotel_center_id, campaign.id, campaign.local_campaign_setting.location_source_type, campaign.local_services_campaign_settings.category_bids, campaign.manual_cpa, campaign.manual_cpc.enhanced_cpc_enabled, campaign.manual_cpm, campaign.manual_cpv, campaign.maximize_conversion_value.target_roas, campaign.maximize_conversions.target_cpa_micros, campaign.name, campaign.network_settings.target_content_network, campaign.network_settings.target_google_search, campaign.network_settings.target_partner_search_network, campaign.network_settings.target_search_network, campaign.optimization_goal_setting.optimization_goal_types, campaign.optimization_score, campaign.payment_mode, campaign.percent_cpc.cpc_bid_ceiling_micros, campaign.percent_cpc.enhanced_cpc_enabled, campaign.performance_max_upgrade.performance_max_campaign, campaign.performance_max_upgrade.pre_upgrade_campaign, campaign.performance_max_upgrade.status, campaign.real_time_bidding_setting.opt_in, campaign.resource_name, campaign.selective_optimization.conversion_actions, campaign.serving_status, campaign.shopping_setting.campaign_priority, campaign.shopping_setting.enable_local, campaign.shopping_setting.feed_label, campaign.shopping_setting.merchant_id, campaign.shopping_setting.sales_country, campaign.shopping_setting.use_vehicle_inventory, campaign.start_date, campaign.status, campaign.target_cpa.cpc_bid_ceiling_micros, campaign.target_cpa.cpc_bid_floor_micros, campaign.target_cpa.target_cpa_micros, campaign.target_cpm, campaign.target_impression_share.cpc_bid_ceiling_micros, campaign.target_impression_share.location, campaign.target_impression_share.location_fraction_micros, campaign.target_roas.cpc_bid_ceiling_micros, campaign.target_roas.cpc_bid_floor_micros, campaign.target_roas.target_roas, campaign.target_spend.cpc_bid_ceiling_micros, campaign.target_spend.target_spend_micros, campaign.targeting_setting.target_restrictions, campaign.tracking_setting.tracking_url, campaign.tracking_url_template, campaign.url_custom_parameters, campaign.url_expansion_opt_out, campaign.vanity_pharma.vanity_pharma_display_url_mode, campaign.vanity_pharma.vanity_pharma_text, campaign.video_brand_safety_suitability, campaign_budget.amount_micros, campaign_budget.delivery_method, campaign_budget.explicitly_shared, campaign_budget.has_recommended_budget, campaign_budget.id, campaign_budget.name, campaign_budget.period, campaign_budget.recommended_budget_amount_micros, campaign_budget.recommended_budget_estimated_change_weekly_clicks, campaign_budget.recommended_budget_estimated_change_weekly_cost_micros, campaign_budget.recommended_budget_estimated_change_weekly_interactions, campaign_budget.recommended_budget_estimated_change_weekly_views, campaign_budget.reference_count, campaign_budget.resource_name, campaign_budget.status, campaign_budget.total_amount_micros, campaign_budget.type, campaign_group.id, campaign_group.name, campaign_group.resource_name, campaign_group.status from campaign where campaign.id   =   \"17796259637\" "

Response
--------
Headers: Metadata(content-type=application/grpc,request-id=_vBEkOHCQh0U_eja49is-g,date=Thu, 08 Sep 2022 21:45:50 GMT,alt-svc=h3=":443"; ma=2592000,h3-29=":443"; ma=2592000,h3-Q050=":443"; ma=2592000,h3-Q046=":443"; ma=2592000,h3-Q043=":443"; ma=2592000,quic=":443"; ma=2592000; v="46,43")
Body: null
Failure message: errors {
  error_code {
    internal_error: INTERNAL_ERROR
  }
  message: "An internal error has occurred."
}
request_id: "_vBEkOHCQh0U_eja49is-g"

Status: Status{code=INTERNAL, description=Internal error encountered., cause=null}.

request-id=_vBEkOHCQh0U_eja49is-g

The Internal Errors rate started elevating after 4pm EST
Pete

Many others reporting this on the forum
https://groups.google.com/g/adwords-api/c/Zcyg7c1X8jY

I think this was an issue that has been fixed at our end.
On Thu, Sep 8, 2022, 6:07 PM Peter Lavetsky @.***>
wrote:

Many others reporting this on the forum
https://groups.google.com/g/adwords-api/c/Zcyg7c1X8jY
—
Reply to this email directly, view it on GitHub
https://github.com/googleads/google-ads-java/issues/671#issuecomment-1241285733,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABCOJCBRE5CXOQCJBNRXW7TV5JPTBANCNFSM6AAAAAAQIE3I3Q
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>

Good to hear Anash! We're no longer seeing the elevated failure rates from before.
Thanks
Pete

We're starting to see these numbers elevate again:
./deadline-exceeded-test.sh
/efs/api/google/requests/new-google-requests-summary.2022-09-12.log 73
/efs/api/google/requests/new-google-requests-summary.2022-09-13.log 192
/efs/api/google/requests/new-google-requests-summary.2022-09-14.log 994

./internal-error-test.sh
/efs/api/google/requests/new-google-requests-summary.2022-09-12.log 14
/efs/api/google/requests/new-google-requests-summary.2022-09-13.log 138
/efs/api/google/requests/new-google-requests-summary.2022-09-14.log 544

traceroute to googleads.googleapis.com (<IP_ADDRESS>), 50 hops max, 60 byte packets
 1  ip-172-31-130-116.us-east-2.compute.internal (<IP_ADDRESS>)  0.120 ms  0.110 ms  0.123 ms
 2  ec2-52-15-0-183.us-east-2.compute.amazonaws.com (<IP_ADDRESS>)  8.616 ms ec2-52-15-0-161.us-east-2.compute.amazonaws.com (<IP_ADDRESS>)  40.989 ms ec2-52-15-0-187.us-east-2.compute.amazonaws.com (<IP_ADDRESS>)  2.709 ms
 3  <IP_ADDRESS> (<IP_ADDRESS>)  14.815 ms <IP_ADDRESS> (<IP_ADDRESS>)  7.087 ms <IP_ADDRESS> (<IP_ADDRESS>)  8.693 ms
 4  <IP_ADDRESS> (<IP_ADDRESS>)  1.701 ms <IP_ADDRESS> (<IP_ADDRESS>)  38.767 ms <IP_ADDRESS> (<IP_ADDRESS>)  5.486 ms
 5  <IP_ADDRESS> (<IP_ADDRESS>)  38.082 ms <IP_ADDRESS> (<IP_ADDRESS>)  17.437 ms <IP_ADDRESS> (<IP_ADDRESS>)  162.246 ms
 6  <IP_ADDRESS> (<IP_ADDRESS>)  0.666 ms <IP_ADDRESS> (<IP_ADDRESS>)  0.700 ms <IP_ADDRESS> (<IP_ADDRESS>)  0.736 ms
 7  <IP_ADDRESS> (<IP_ADDRESS>)  0.634 ms <IP_ADDRESS> (<IP_ADDRESS>)  0.752 ms <IP_ADDRESS> (<IP_ADDRESS>)  0.787 ms
 8  <IP_ADDRESS> (<IP_ADDRESS>)  0.776 ms <IP_ADDRESS> (<IP_ADDRESS>)  0.669 ms <IP_ADDRESS> (<IP_ADDRESS>)  0.675 ms
 9  <IP_ADDRESS> (<IP_ADDRESS>)  1.229 ms <IP_ADDRESS> (<IP_ADDRESS>)  1.302 ms <IP_ADDRESS> (<IP_ADDRESS>)  1.298 ms
10  <IP_ADDRESS> (<IP_ADDRESS>)  2.635 ms <IP_ADDRESS> (<IP_ADDRESS>)  3.372 ms <IP_ADDRESS> (<IP_ADDRESS>)  2.966 ms
11  <IP_ADDRESS> (<IP_ADDRESS>)  1.411 ms <IP_ADDRESS> (<IP_ADDRESS>)  1.918 ms <IP_ADDRESS> (<IP_ADDRESS>)  1.350 ms
12  <IP_ADDRESS> (<IP_ADDRESS>)  1.126 ms <IP_ADDRESS> (<IP_ADDRESS>)  1.502 ms <IP_ADDRESS> (<IP_ADDRESS>)  4.611 ms
13  <IP_ADDRESS> (<IP_ADDRESS>)  14.115 ms <IP_ADDRESS> (<IP_ADDRESS>)  11.614 ms <IP_ADDRESS> (<IP_ADDRESS>)  16.294 ms
14  <IP_ADDRESS> (<IP_ADDRESS>)  11.637 ms <IP_ADDRESS> (<IP_ADDRESS>)  12.646 ms <IP_ADDRESS> (<IP_ADDRESS>)  11.611 ms
15  <IP_ADDRESS> (<IP_ADDRESS>)  11.347 ms <IP_ADDRESS> (<IP_ADDRESS>)  11.588 ms <IP_ADDRESS> (<IP_ADDRESS>)  11.452 ms
16  <IP_ADDRESS> (<IP_ADDRESS>)  12.192 ms <IP_ADDRESS> (<IP_ADDRESS>)  11.631 ms <IP_ADDRESS> (<IP_ADDRESS>)  11.464 ms
17  <IP_ADDRESS> (<IP_ADDRESS>)  11.576 ms <IP_ADDRESS> (<IP_ADDRESS>)  11.485 ms <IP_ADDRESS> (<IP_ADDRESS>)  14.864 ms
18  <IP_ADDRESS> (<IP_ADDRESS>)  11.420 ms  11.290 ms <IP_ADDRESS> (<IP_ADDRESS>)  11.357 ms
19  <IP_ADDRESS> (<IP_ADDRESS>)  12.027 ms <IP_ADDRESS> (<IP_ADDRESS>)  11.378 ms <IP_ADDRESS> (<IP_ADDRESS>)  11.199 ms
20  <IP_ADDRESS> (<IP_ADDRESS>)  11.638 ms <IP_ADDRESS> (<IP_ADDRESS>)  12.735 ms <IP_ADDRESS> (<IP_ADDRESS>)  12.669 ms
21  * * <IP_ADDRESS> (<IP_ADDRESS>)  12.579 ms
22  <IP_ADDRESS> (<IP_ADDRESS>)  12.536 ms <IP_ADDRESS> (<IP_ADDRESS>)  12.523 ms <IP_ADDRESS> (<IP_ADDRESS>)  19.683 ms
23  <IP_ADDRESS> (<IP_ADDRESS>)  12.603 ms <IP_ADDRESS> (<IP_ADDRESS>)  11.534 ms <IP_ADDRESS> (<IP_ADDRESS>)  12.930 ms
24  <IP_ADDRESS> (<IP_ADDRESS>)  12.564 ms <IP_ADDRESS> (<IP_ADDRESS>)  18.983 ms <IP_ADDRESS> (<IP_ADDRESS>)  18.328 ms
25  * <IP_ADDRESS> (<IP_ADDRESS>)  13.272 ms <IP_ADDRESS> (<IP_ADDRESS>)  18.431 ms
26  * <IP_ADDRESS> (<IP_ADDRESS>)  19.876 ms *
27  <IP_ADDRESS> (<IP_ADDRESS>)  17.802 ms <IP_ADDRESS> (<IP_ADDRESS>)  17.944 ms ord38s32-in-f10.1e100.net (<IP_ADDRESS>)  17.985 ms

 5  <IP_ADDRESS> (<IP_ADDRESS>)  38.082 ms <IP_ADDRESS> (<IP_ADDRESS>)  17.437 ms <IP_ADDRESS> (<IP_ADDRESS>)  162.246 ms

Pete

Hi Pete,
We're looking into this and I'll get back to you. Thanks for highlighting it.
-Josh

Hey Josh,
The errors seem to have backed off, but over the last two days we've seen very anomalous mutate durations for two specific calls:
CampaignBudgetServiceClient mutateCampaignBudgets
CampaignServiceClient mutateCampaigns
Here are the last couple days worth of average job times ( in seconds ) for mutateCampaignBudgets jobs ... these times are not strictly the mutate call, but I know from additional metric collection that the majority of the time is on the campaignBudgetServiceClient.mutateCampaignBudgets( request ) call
2022-09-14	42.42
2022-09-13	8.8
2022-09-12	8.82
2022-09-11	7.3
2022-09-10	6.35
2022-09-09	7.41

Same caveats for campaignServiceClient.mutateCampaigns( request )
2022-09-14	154.06
2022-09-13	38.04
2022-09-12	32.47
2022-09-11	27.55
2022-09-10	25.71
2022-09-09	30

Pete

Hi Pete,
The issues with GoogleAdsService.searchStream were due to a temporary problem that was resolved within 24 hours. Are you still seeing issues with streaming requests or the mutate requests you mentioned?
Thanks

Hi Josh,
Things seem back to normal.
Thanks
Pete

Thanks for confirming. Will close this one again then.

Josh,
It gives me no pleasure to report that soon after our last correspondence this issue has come back up, with an additional kicker of getting errors of RESOURCE_EXHAUSTED:
Caused by: com.google.ads.googleads.v11.errors.GoogleAdsException: errors {
error_code {
quota_error: RESOURCE_EXHAUSTED
}
message: "Too many requests. Retry in 900 seconds."
}
request_id: "ATmfNRHuaclFOBdipYLP9Q"

We have not changed any code, nor significantly increased our request load.
GoogleAdsServiceClient searchStreamCallable requests started seeing a noticeable slowdown starting around 5pm EST on 9/26, soon after we closed this issue down. Around 2am EST on 9/27 the response times were about 400% slower and at 4am EST this morning the search response times were about 2,000% slower than what we normally enjoy.
The following hours are UTC and the times noted are in seconds.
Day.                Hour Average Job Time
2022-09-26	8	1.9725
2022-09-26	9	1.932
2022-09-26	10	2.9016
2022-09-26	11	1.8385
2022-09-26	12	2.1983
2022-09-26	13	2.5466
2022-09-26	14	2.674
2022-09-26	15	1.9535
2022-09-26	16	1.6244
2022-09-26	17	1.4612
2022-09-26	18	1.4646
2022-09-26	19	1.3422
2022-09-26	20	1.5366
2022-09-26	21	3.6096
2022-09-26	22	4.02
2022-09-26	23	3.0292
2022-09-27	0	2.4258
2022-09-27	1	4.9145
2022-09-27	2	4.6897
2022-09-27	3	6.3486
2022-09-27	4	4.0788
2022-09-27	5	4.1629
2022-09-27	6	10.0844
2022-09-27	7	24.1455
2022-09-27	8	43.9109

./resource-exhausted-test.sh
/efs/api/google/requests/new-google-requests-summary.2022-09-25.log 0
/efs/api/google/requests/new-google-requests-summary.2022-09-26.log 0
/efs/api/google/requests/new-google-requests-summary.2022-09-27.log 496

./deadline-exceeded-test.sh
/efs/api/google/requests/new-google-requests-summary.2022-09-25.log 40
/efs/api/google/requests/new-google-requests-summary.2022-09-26.log 37
/efs/api/google/requests/new-google-requests-summary.2022-09-27.log 404

We're certainly not here to report every minor fluctuation in service response, but these do look to be significantly anomalous and we ( and I assume many others ) are currently being severely impacted by a degraded search service.
One specific GoogleAdsServiceClient searchStreamCallable heavy job that routinely takes under 2 hours to complete is now entering it's 5th hour with about 25% of its workload still to be completed.
As always, any additional details you may request I am happy to provide and any guidance you may offer will be gratefully accepted.
Thanks
Pete

Hi Pete,
The root cause of the latest issue you highlighted has been fixed and traffic should be back to normal now. Appreciate you sharing the results of your monitoring as well. I'm working with the team to improve monitoring on our side (based on what we discovered as a result of the most recent problem) so we can be alerted to these issues sooner.
Thanks,
Josh

Hi All,
Just wanted to highlight that we're currently getting a very high rate of Deadline Exceeded exceptions
google-requests-summary.2023-06-19.log 12447
google-requests-summary.2023-06-18.log 10
google-requests-summary.2023-06-17.log 349
google-requests-summary.2023-06-16.log 91
google-requests-summary.2023-06-15.log 56

traceroute to googleads.googleapis.com (<IP_ADDRESS>), 50 hops max, 60 byte packets
 1  ip-172-31-67-206.us-east-2.compute.internal (<IP_ADDRESS>)  0.129 ms  0.116 ms  0.119 ms
 2  ec2-52-15-0-51.us-east-2.compute.amazonaws.com (<IP_ADDRESS>)  9.925 ms ec2-52-15-0-31.us-east-2.compute.amazonaws.com (<IP_ADDRESS>)  3.526 ms ec2-52-15-0-39.us-east-2.compute.amazonaws.com (<IP_ADDRESS>)  5.206 ms
 3  <IP_ADDRESS> (<IP_ADDRESS>)  30.440 ms <IP_ADDRESS> (<IP_ADDRESS>)  4.696 ms <IP_ADDRESS> (<IP_ADDRESS>)  5.844 ms
 4  <IP_ADDRESS> (<IP_ADDRESS>)  7.660 ms <IP_ADDRESS> (<IP_ADDRESS>)  4.232 ms <IP_ADDRESS> (<IP_ADDRESS>)  53.682 ms
 5  <IP_ADDRESS> (<IP_ADDRESS>)  19.706 ms <IP_ADDRESS> (<IP_ADDRESS>)  15.285 ms <IP_ADDRESS> (<IP_ADDRESS>)  47.163 ms
 6  <IP_ADDRESS> (<IP_ADDRESS>)  0.788 ms <IP_ADDRESS> (<IP_ADDRESS>)  0.756 ms <IP_ADDRESS> (<IP_ADDRESS>)  0.747 ms
 7  <IP_ADDRESS> (<IP_ADDRESS>)  1.390 ms <IP_ADDRESS> (<IP_ADDRESS>)  2.196 ms <IP_ADDRESS> (<IP_ADDRESS>)  1.457 ms
 8  <IP_ADDRESS> (<IP_ADDRESS>)  12.261 ms <IP_ADDRESS> (<IP_ADDRESS>)  12.290 ms <IP_ADDRESS> (<IP_ADDRESS>)  12.554 ms
 9  <IP_ADDRESS> (<IP_ADDRESS>)  12.218 ms <IP_ADDRESS> (<IP_ADDRESS>)  12.185 ms <IP_ADDRESS> (<IP_ADDRESS>)  12.657 ms
10  <IP_ADDRESS> (<IP_ADDRESS>)  11.935 ms <IP_ADDRESS> (<IP_ADDRESS>)  12.182 ms <IP_ADDRESS> (<IP_ADDRESS>)  18.098 ms
11  <IP_ADDRESS> (<IP_ADDRESS>)  13.281 ms * *
12  * * *
13  <IP_ADDRESS> (<IP_ADDRESS>)  13.046 ms <IP_ADDRESS> (<IP_ADDRESS>)  12.650 ms <IP_ADDRESS> (<IP_ADDRESS>)  14.032 ms
14  <IP_ADDRESS> (<IP_ADDRESS>)  14.570 ms  13.528 ms <IP_ADDRESS> (<IP_ADDRESS>)  12.438 ms
15  <IP_ADDRESS> (<IP_ADDRESS>)  15.045 ms * *
16  <IP_ADDRESS> (<IP_ADDRESS>)  14.478 ms <IP_ADDRESS> (<IP_ADDRESS>)  14.216 ms  14.396 ms
17  * <IP_ADDRESS> (<IP_ADDRESS>)  20.519 ms *
18  <IP_ADDRESS> (<IP_ADDRESS>)  18.404 ms  19.463 ms <IP_ADDRESS> (<IP_ADDRESS>)  19.822 ms
19  <IP_ADDRESS> (<IP_ADDRESS>)  19.251 ms <IP_ADDRESS> (<IP_ADDRESS>)  18.455 ms <IP_ADDRESS> (<IP_ADDRESS>)  19.544 ms
20  <IP_ADDRESS> (<IP_ADDRESS>)  19.505 ms <IP_ADDRESS> (<IP_ADDRESS>)  19.945 ms  19.645 ms
21  ord38s31-in-f10.1e100.net (<IP_ADDRESS>)  19.411 ms  18.886 ms  19.663 ms

Intending to ride it out but raising for awareness here if there's anything that can be done to expedite the solution.
Thanks
Pete


System cluster problem: "ModuleNotFoundError: No module named 'seisflows'"

I am running Seisflows from an Anaconda environment. When using the system option "Cluster", I get the error "ModuleNotFoundError: No module named 'seisflows'". I see that cluster.py runs subprocess.run to run several instances of Specfem. As I understand it, each subprocess will not run in the same Anaconda environment as the parent process, but the default environment instead, thus not having access to Seisflows. It looks like the workaround is to explicitly use sys.executable within the subprocess call: https://stackoverflow.com/questions/51819719/using-subprocess-in-anaconda-environment.
However, I am confused as to why cluster's submit operation was working for anybody, if this is the case. I assume that Seisflows users are using a virtual environment, likely Conda. Importantly, I was running cluster just fine up until a few weeks ago.
I included some files that can be ran to show the problem.
test_subprocess_failure_cluster.zip

I played with the different shells, and somehow got the code to work again. For some reason, if executing from zsh, the subprocesses did not have access to the Anaconda bin of my environment. I switched to tcsh on a whim, and things are working now. I updated Conda along the way, and maybe this was the magic trick. It seems like everything is running from zsh again as well (for now). If somebody else runs into this problem, I recommend updating Conda and making a simple test script to check the environment that Python opens in when using subprocess.run.

Hey @brennanbrunsvik, thanks for bringing this up, glad an update was able to solve that! It's always tricky trying to finagle a Python environment to work on suprocesess/compute nodes!


Add hacking to test requirements

Without this module test would not pass

We already have hacking in dev-requirements.txt and it's not required for all tests (only tox -e flake8). I don't like too much hacking both dev-requirements.txt and test-requirements.txt, this is confusing.
I suggest to only keep test-requirements.txt and declare explicitly requirements for each environment in tox.ini


There are still things todo with the grid

still TODO:
more efficent search for neighbours
detection of other traversaltypes
Update passability
#2

Done
#16


Support AWS Bedrock Models

Describe the need of your request
Is it possible to connect AWS Bedrock LLM Models?
Proposed solution
Add AWS Bedrock configuration to config list
Additional context
No response

@carlrobertoh
i can take a look at it. would it be ok to include the aws sdk as dependency? that would make it much easier. checked out your llm-client repo, but rebuilding the Sig4 signing needed to perform rest calls to aws services is quite some effort and there is basically already a bedrock client in the aws sdk


feat: support most remote urls

fork #834

This adds support for s3:// http:// https:// and most other go-getter style urls by
Adding http downloader
Adding s3 downloader that authenticates with aws sdk shared credentials
Changing the parser to accept remote formats that do not include '::'
Removing validation that required go-getter urls to contain '@' which is not required by go-getter spec
Resolves https://github.com/helmfile/helmfile/issues/831

@xiaomudk are there breaking changes?

@xiaomudk are there breaking changes?

No, all changes are backward compatible.

@xiaomudk How did you test this is backward-compatible?
Also,

Removing validation that required go-getter urls to contain '@' which is not required by go-getter spec

How does it work without @ now?
I vaguely remember that we used @ to specify the relative path to the directory that you want helmfile to download and use as a chart.
https://github.com/roboll/helmfile/pull/1374

first question:
Unit test: TestRemote_HttpsGitHub, TestRemote_SShGitHub, TestRemote_SShGitHub_WithSshKey all passed normally
second question:
Without @, the root directory in the url starts as a subdirectory
        pathComponents := strings.Split(u.Path, "@")
	if len(pathComponents) != 2 {
		dir := filepath.Dir(u.Path)
		if len(dir) > 0 {
			dir = dir[1:]
		}
		pathComponents = []string{dir, filepath.Base(u.Path)}
	}


Convert Existing Cypress tests to Typescript

Currently all the Cypress step definitions and page classes are written in Javascript.
It would be good to convert all of them to Typescript.

Possible issues with custom Cypress commands and conflicts with Jest.

https://docs.cypress.io/guides/tooling/typescript-support#Install-TypeScript

Declaring global in the Cypress commands file seems to stop the cypress command errors


docs/brew-tap.md: Reference dunn's Emacs tap

edavis' repo currently points to homebrew/emacs,
which has since been moved to dunn/emacs.
Signed-off-by: Bob W. Hogg<EMAIL_ADDRESS>
[x] Have you followed the guidelines in our Contributing document?
[x] Have you checked to ensure there aren't other open Pull Requests for the same change?
[x] Have you added an explanation of what your changes do and why you'd like us to include them?
[ ] Have you written new tests for your changes? Here's an example.
[x] Have you successfully run brew tests with your changes locally?

Thanks again @rwhogg!


Add Bashly to "For Developers"

GitHub repo: https://github.com/DannyBen/bashly
(but added the documentation home in the link)

Thanks, included Bashly in the Shell Script Development section in 63607b5426919322668b18a6bdc2f492cdc0fb79.


RunTransaction - mutableData doesnt retrieve on Android 1st time

Unity editor version:
Firebase Unity SDK version: 6.2.2
Firebase plugins in use (Auth, Database, etc.): Auth, Database
Additional SDKs you are using (Facebook, AdMob, etc.): Mapbox
Platform you are using the Unity editor on (Mac, Windows, or Linux): Windows
Platform you are targeting (iOS, Android, and/or desktop): Android
Hello. I have this code:
ref.Child("child1").Child("child2").Child(child3).RunTransaction(mutableData =>
{
string something = (string)mutableData.Child("childname").Value;
...
}
In Unity editor, everything works fine. But when I try it on my android phone (Honor 10), it works like that:
first call: transaction aborted, since string something is empty
second call: transaction succesfull, value of string something returned correctly
Where can be the issue? Is there any way how to eliminate it except running the transaction again?
Also I am doing same thing somewhere else with a bool value and it works fine. So I dont know.
Edit: tried it on my second android phone. Same issue.

When the transaction runs, it operates on whatever data is in your local cache of the database. If there is no data there, it will still try to run. This is by design, it will re-run again when the data at that location is updated, and keep trying to run the transaction until it is successful.
Take a look at this for more details.
For this reason, you should make sure that your transaction can be safely run multiple times, and can fail gracefully if there is no data present. If you want to ensure that you have up to date data that your transaction can operate on, you can try setting KeepSynced on the location in the database you want to operate on. This will ensure that the data is kept up to date, so if you run a transaction on that location it should get the most up to date data on the first try. (Note though  that this does not guarantee that your transaction will be called only once - if another client changes that location while you are operating on it, your transaction may need to run a second time)

I am not sure if I understand correctly.
I mean there are data in the node, like some string. I run transaction  for the first time, it just return empty string in mutable data, instead of string with some text, which is stored in the node. And on the second time (nothing changes in db), it returns correct string. Also the issue is only on Android devices, not in unity editor. So this behavior can be correct?
So I mean should I like loop that transaction few times then?

Hi @craNich,
Part of the design of this is to help you gracefully deal with spotty connections or just users in airplane mode (for me, this is major pain point of developing asynchronous multiplayer games). You can happily shove data into a database in whatever network condition exists, know that your app won't grind to a halt, and be able to still gracefully handle merging data in the transaction once you regain connection.
I can think of two disadvantages of KeepSynced:

if your user is offline on the first run, even with KeepSynced set to true, you may still get empty data. You'll still want to be able to handle this case. If setting KeepSynced appears to fix your game, you may actually just be hiding a difficult to trace bug.
Realtime Database acts like this so it doesn't pull data down until you absolutely need it. If this is something you'll be accessing often, it might be a good idea to set KeepSynced anyway. If this is something you might only access once a session or once every few sessions, you'll be spending a lot of time keeping something updated that doesn't need to be.

Let me know if this all helps and I can close this thread. Otherwise, feel free to keep asking questions. I'm sure all of this is useful information for anyone else researching Realtime Database behaviour.
--Patrick


Config file not updated when 'current_version' does not match template defined in 'serialize'

This issue is related to #179.
Given the following config:
current_version = "1.0.0"
parse = "(?P<major>\\d+)\\.(?P<minor>\\d+)\\.(?P<patch>\\d+)"
serialize = ["{major}.{minor:02d}.{patch}"]
search = "{current_version}"
replace = "{new_version}"

The config file's current version is not updated due to a regex pattern mismatch. Thus, committing also fails.
I wouldn't say that this is an error per se as one would assume that current_version should match the pattern specified in serialize but I saw that there are multiple entries for current_version in context when the regex pattern is determined and it is picking the zero-padded one instead of the one which is specified in the config.
If this could be solved without much effort I would be happy. Otherwise I'm also fine.

Could you paste in the output of what happens when you do a bump but add -vv into the command to turn on verbose output?
That would help me identify where the problem is.

[tool.bumpversion]
current_version = "1.0.0"
serialize = ["{major}.{minor:02}.{patch}"]
tag = true
commit = true
allow_dirty = true

Starting BumpVersion 0.20.2
Reading configuration
  Reading config file: ***\.bumpversion.toml
  Parsing current version '1.0.0'
    Parsing version '1.0.0' using regexp '(?P<major>\d+)\.(?P<minor>\d+)\.(?P<patch>\d+)'
      Parsed the following values: major=1, minor=0, patch=0
  Attempting to increment part 'minor'
    Values are now: major=1, minor=1, patch=0
  Serializing version '<bumpversion.Version:major=1, minor=1, patch=0>'
    Using serialization format '{major}.{minor:02}.{patch}'
    Serialized to '1.01.0'
  New version will be '1.01.0'

Processing config file: ***\.bumpversion.toml
  Serializing version '<bumpversion.Version:major=1, minor=0, patch=0>'
    Using serialization format '{major}.{minor:02}.{patch}'
    Serialized to '1.00.0'
  Serializing version '<bumpversion.Version:major=1, minor=1, patch=0>'
    Using serialization format '{major}.{minor:02}.{patch}'
    Serialized to '1.01.0'
  Rendering search pattern with context
    No RegEx flag detected. Searching for the default pattern: '1\.00\.0'
  Not changing file ***\.bumpversion.toml:tool.bumpversion.current_version
Preparing Git commit
  Adding changes in file '***\.bumpversion.toml' to Git
  Committing to Git with message 'Bump version: 1.0.0 → 1.01.0'
  Failed to run ['git', 'commit', '-F', '***\\AppData\\Local\\Temp\\tmpaxtkaxbo']: return code 1, output:
b'On branch main\nYour branch is up to date with \'origin/main\'.\n\n...'

@coordt any news on this one?

So here is the story: The logic for changing the config file intentionally does not change mismatching contents to avoid accidents.
I believe this mismatch should only be temporary or a true error. I'm willing to hear how this might be a long-term problem and what methods are available to prevent this behavior.

Ok, thanks for clarification. For me the linked error is not raised as ignore_missing_version seems to be always set to true here.
But anyways, I am fine with it as it should only be relevant in case the versioning scheme changes.


Have submodules/wraps use https instead of git@

Fixed in the monorepo, distributing the changes (and some others) from there. Thanks for the contribution!