Error initializing DirectLine client TypeError: Cannot read property 'add' of undefined

I just change the var directLineSecret = 'MySecretKey';
and install in local repository by following command:
npm install swagger-client
npm install -g open
npm install --save request
npm install --save request-promise
BotBuilder main repository
(https://github.com/Microsoft/BotBuilder-Samples/tree/master/Node/core-DirectLine)
URL of Code Sample
(https://github.com/Microsoft/BotBuilder-Samples/blob/master/Node/core-DirectLineWebSockets/DirectLineClient/app.js#L32-L45)
Problem Description
Error initializing DirectLine client TypeError: Cannot read property 'add' of un
defined

Unhandled rejection TypeError: Cannot read property 'Conversations' of undefined

Probably the same issue #191

@MilkoKunev i run the command that he provided.. but still same error

hi there, sorry for respond on closed issue, the version of swagger-client that works is "2.1.18".


Forwarding POST request to downstream .NET service is failing when downstream service is Kerberos/Windows Auth protected

Describe the bug
A clear and concise description of what the bug is.
Forwarding POST request to downstream .NET service is failing when downstream service is Auth protected
To Reproduce
What steps can we follow to reproduce the issue?
Components

Downstream service  (service1) has windows AUTH enabled  which is written in .NET 4.X

YARP is enabled like as below with no auth on YARP (proxy)
services.AddReverseProxy()
.ConfigureHttpClient((context, handler) =>
{
handler.Credentials=CredentialCache.DefaultCredentials;
handler.UseProxy=false;
})

Testing Scenarios with sample .NET 5 console application

GET proxy/service1/endpoint1 Works

Fiddler trace shows two requests
a) 401 without any authentication headers
b) 200 with www-authenticate Negotiate

POST proxy/service1/endpoint1 Fails

Fiddler trace shows 1 request
a)  401 without any authentication header

When there is no AUTH in downstream services everything works fine.

Got Exceptions? Include both the message and the stack trace
-->
System.Net.Http.HttpRequestException: An error occurred while sending the request.
---> System.InvalidOperationException: The stream was already consumed.
at Yarp.ReverseProxy.Forwarder.StreamCopyHttpContent.SerializeToStreamAsync(Stream stream, TransportContext context, CancellationToken cancellationToken)
at System.Net.Http.HttpContent.CopyToAsyncCore(ValueTask copyTask)
at System.Net.Http.HttpConnection.SendRequestContentAsync(HttpRequestMessage request, HttpContentWriteStream stream, CancellationToken cancellationToken)
at System.Net.Http.HttpConnection.SendAsyncCore(HttpRequestMessage request, CancellationToken cancellationToken)
--- End of inner exception stack trace ---
at System.Net.Http.HttpConnection.SendAsyncCore(HttpRequestMessage request, CancellationToken cancellationToken)
at System.Net.Http.AuthenticationHelper.SendWithNtAuthAsync(HttpRequestMessage request, Uri authUri, ICredentials credentials, Boolean isProxyAuth, HttpConnection connection, HttpConnectionPool connectionPool, CancellationToken cancellationToken)
at System.Net.Http.HttpConnectionPool.SendWithNtConnectionAuthAsync(HttpConnection connection, HttpRequestMessage request, Boolean doRequestAuth, CancellationToken cancellationToken)
at System.Net.Http.HttpConnectionPool.SendWithRetryAsync(HttpRequestMessage request, Boolean doRequestAuth, CancellationToken cancellationToken)
at System.Net.Http.AuthenticationHelper.SendWithAuthAsync(HttpRequestMessage request, Uri authUri, ICredentials credentials, Boolean preAuthenticate, Boolean isProxyAuth, Boolean doRequestAuth, HttpConnectionPool pool, CancellationToken cancellationToken)
at  Yarp.ReverseProxy.Forwarder SendAsync
same is the issue even when downstream service is in .NET 5 Linux
Further technical details

Include the version of the packages you are using
Yarp.ReverseProxy : Version= 1.0.0

The platform (Linux/macOS/Windows)

Windows

Which user are you expecting to authenticate to the destination service as? CredentialCache.DefaultCredentials will give you the user that's running the proxy process, not the user from the client. YARP does not support end-to-end Negotiate/Windows/Kerberos auth, though it should be possible from the client to proxy or from proxy to destination.
Negotiate auth requires a multi-request handshake. This is a problem for POST requests because even when it receives the first 401 response, it has to send the request body. The proxy does not buffer the request body by default, so it's unable to replay the body later after the 200 response. To mitigate this you either need to enable Expect: 100-continue on the requests, or to buffer the requests (HttpRequestMessage.Content.LoadIntoBufferAsync() in a request transform).

Which user are you expecting to authenticate to the destination service as?  => Yes,  I am not trying delegation here but   Negotiate/Windows/Kerberos from proxy to destination.
I had already tried adding Expect: 100-continue in the request transform as
{"RequestHeader": "Expect", "Set" : "100-continue"}
but it does not work though after setting this I see 408 in fiddler where YARP is sending "Content-Length"=:some number" on 2nd request but body as empty
Not sure what do you mean by that  (HttpRequestMessage.Content.LoadIntoBufferAsync() in a request transform) because I can't find anything like that here or using config as well.
.AddTransforms(builderContext =>
{
        builderContext.AddRequestTransform(async transformContext =>
        {
           **//Here**
        });

});

PS: I am not using any custom forwarder but default one from YARP.

(HttpRequestMessage.Content.LoadIntoBufferAsync() in a request transform) => it worked , does it has side effect on the flow? or there is a better way doing it to avoid performance hit?

There's definitely a perf hit, especially for large bodies. You'll have to measure to see if it's acceptable.
I'm not aware of other workarounds you can try beyond switching the auth type.

Thanks @Tratcher Which user are you expecting to authenticate to the destination service as? => Yes, I am not trying delegation here but Negotiate/Windows/Kerberos from proxy to destination.
I had already tried adding Expect: 100-continue in the request transform as {"RequestHeader": "Expect", "Set" : "100-continue"} but it does not work though after setting this I see 408 (Request Body Incomplete) in fiddler where YARP is sending "Content-Length"=some number" on 2nd request but body as empty
(HttpRequestMessage.Content.LoadIntoBufferAsync() in a request transform) => it worked , does it has side effect on the flow? or there is a better way doing it to avoid performance hit?

Samanthwal,
Would it be possible for you to share the YARP code in which you implement this? I trying to do the same as you, but currently without success (and I've spent days!).
Thank you so much in advance =)

Hi,
thank you so much! You made not only my day, but my entire week! \o/
I wish you a great day :-)
All the best,
Mike


Support Envoy LocalReplyConfig Settings

xref: https://www.envoyproxy.io/docs/envoy/v1.25.0/configuration/http/http_conn_man/local_reply.html?highlight=local reply
apiVersion: config.gateway.envoyproxy.io/v1alpha1
kind: EnvoyProxy
metadata:
  name: with-local-reply-config
spec:
  localReplyConfig:
    mappers:
    - filter:
        status_code_filter:
          comparison:
            op: EQ
            value:
              default_value: 400
              runtime_key: key_b
      status_code: 401
      body_format_override:
        text_format: "<h1>%LOCAL_REPLY_BODY% %REQ(:path)%</h1>"
        content_type: "text/html; charset=UTF-8"
    - filter:
        status_code_filter:
          comparison:
            op: EQ
            value:
              default_value: 500
              runtime_key: key_b
      status_code: 501
    bodyFormat:
      text_format: "%LOCAL_REPLY_BODY% %RESPONSE_CODE%"

using the go-control-panel API, so some file naming styles followed
API definition
// EnvoyProxySpec defines the desired state of EnvoyProxy.
type EnvoyProxySpec struct {
	// Provider defines the desired resource provider and provider-specific configuration.
	// If unspecified, the "Kubernetes" resource provider is used with default configuration
	// parameters.
	//
	// +optional
	Provider *EnvoyProxyProvider `json:"provider,omitempty"`

	// Logging defines logging parameters for managed proxies. If unspecified,
	// default settings apply. This type is not implemented until
	// https://github.com/envoyproxy/gateway/issues/280 is fixed.
	//
	// +kubebuilder:default={level: {system: info}}
	Logging ProxyLogging `json:"logging,omitempty"`

	// Bootstrap defines the Envoy Bootstrap as a YAML string.
	// Visit https://www.envoyproxy.io/docs/envoy/latest/api-v3/config/bootstrap/v3/bootstrap.proto#envoy-v3-api-msg-config-bootstrap-v3-bootstrap
	// to learn more about the syntax.
	// If set, this is the Bootstrap configuration used for the managed Envoy Proxy fleet instead of the default Bootstrap configuration
	// set by Envoy Gateway.
	// Some fields within the Bootstrap that are required to communicate with the xDS Server (Envoy Gateway) and receive xDS resources
	// from it are not configurable and will result in the `EnvoyProxy` resource being rejected.
	// Backward compatibility across minor versions is not guaranteed.
	// We strongly recommend using `egctl x translate` to generate a `EnvoyProxy` resource with the `Bootstrap` field set to the default
	// Bootstrap configuration used. You can edit this configuration, and rerun `egctl x translate` to ensure there are no validation errors.
	//
	// +optional
	Bootstrap *string `json:"bootstrap,omitempty"`

	// The configuration to customize local reply returned by Envoy. It can customize status code,
	// body text and response content type. If not specified, status code and text body are hard
	// coded in Envoy, the response content type is plain text.
	//
	// +optional
	LocalReplyConfig *LocalReplyConfig `json:"localReplyConfig,omitempty"`
}

type LocalReplyConfig struct {

	// Configuration of list of mappers which allows to filter and change local response.
	// The mappers will be checked by the specified order until one is matched.
	Mappers []*hcmv3.ResponseMapper `json:"mappers,omitempty"`
	// The configuration to form response body from the :ref:`command operators <config_access_log_command_operators>`
	// and to specify response content type as one of: plain/text or application/json.
	//
	// Example one: "plain/text" ``body_format``.
	//
	// .. validated-code-block:: yaml
	//   :type-name: envoy.config.core.v3.SubstitutionFormatString
	//
	//   text_format: "%LOCAL_REPLY_BODY%:%RESPONSE_CODE%:path=%REQ(:path)%\n"
	//
	// The following response body in "plain/text" format will be generated for a request with
	// local reply body of "upstream connection error", response_code=503 and path=/foo.
	//
	// .. code-block:: text
	//
	//   upstream connect error:503:path=/foo
	//
	// Example two: "application/json" ``body_format``.
	//
	// .. validated-code-block:: yaml
	//   :type-name: envoy.config.core.v3.SubstitutionFormatString
	//
	//   json_format:
	//     status: "%RESPONSE_CODE%"
	//     message: "%LOCAL_REPLY_BODY%"
	//     path: "%REQ(:path)%"
	//
	// The following response body in "application/json" format would be generated for a request with
	// local reply body of "upstream connection error", response_code=503 and path=/foo.
	//
	// .. code-block:: json
	//
	//  {
	//    "status": 503,
	//    "message": "upstream connection error",
	//    "path": "/foo"
	//  }
	//
	BodyFormat *corev3.SubstitutionFormatString `json:"bodyFormat,omitempty"`
}

what's the use case? please make an agreement before starting to work

what's the use case? please make an agreement before starting to work

custom the exception error page or message, like 503, 500, 404 or others

like this?
so I think is a kind of route or per listener?

like this? so I think is a kind of route or per listener?

the locaReplyConfig is a setting for HttpConnectionManager. and it is different  from DirectResponse

hoping #24 can solve your issue
I will also raise a issue upstream for a ResponseBodyModifier filter

raised https://github.com/kubernetes-sigs/gateway-api/issues/1998

Imo, the ResponseBodyModifier is a filter for route, but the localReplyConfig is the global exception config

I recall there's an upstream issue about global filter, @arkodg do you recall anything?

temporarily assigning this to you @davidalger,  tia !

renaming this feature and issue to Custom Error Response to better highlight the use case
this feature can focus on 2 things

custom body and status code based on a specific match from local response.
custom body and status code based on a specific match from upstream response

we can separate out Direct Response ( tracked with https://github.com/envoyproxy/gateway/issues/2714 )
a good home for this feature can be BackendTrafficPolicy
we can either use the LocalReply filter and/or the CustomResponse filter  to implement the API

wdyt @envoyproxy/gateway-maintainers @envoyproxy/gateway-reviewers

moving this to v1.2 to track docs


Transparency issue with pop-up from left panel when it overlaps into the main area

The pop-up from something like the missions or junctions box is transparent and has issues when it renders over content on the main page vs. the pop-up on the main page itself being fully opaque.

Example of it being opaque in the main content area. (It seems to be transparent when coming from the left panel is what I'm trying to point out and when it's not coming from the left panel it's fully opaque.)


testing issues mail

@sauergeek this is a test.  reply to this email please

Hand-typing SMTP at one of the MXes for this address worked.
Now to figure out why ours doesn't.
MJB
On 2/24/2015 1:55 PM, Norman Ramsey wrote:

@sauergeek https://github.com/sauergeek this is a test. reply to
this email please
—
Reply to this email directly or view it on GitHub
https://github.com/nrnrnr/ebnf/issues/1.


Error occured at SFT training

Hi, I'm reproducing your job.
When I use the round3_training_data.json data to sft the deepseek-math-7b-base-value_model (after added value head), I got below error:
File "/home/workspace/LLaMA-Factory-0.6.1/LLaMA-Factory/src/llmtuner/train/sft/trainer.py", line 138, in compute_loss
    lm_logits, loss, values = model(**inputs, output_hidden_states=True, return_dict=True)
ValueError: not enough values to unpack (expected 3, got 2)

I added the modified compute_loss function you offered in this page, to the llama_factory CustomSeq2SeqTrainer class to override the original compute_loss of transformers Trainer class.
 How to solve it?

Thank you for your interest in our work. You should invoke the AutoModelForCausalLMWithValueHead in trl for training to avoid this error.
You can refer to Section Model Loader in our implementation_details.md for more details. I have updated this file, and thanks for your good question.

Additionally, you should use bf16 in your training script instead of fp16 to avoid any potential errors.

Thanks a lot! I can start the training process referring to the Model Loader section.

Hi, I have encountered another problem and would like to ask for your advice.
I try to evaluate the intermediate checkpoint by running the script configs/sbs_sft.yaml. But it came to below error:
Traceback (most recent call last):
  File "/home/workspace/Super_MARIO/solver_demo.py", line 47, in <module>
    solver = Solver(config=config)
  File "/home/workspace/Super_MARIO/mcts_math/solver.py", line 73, in __init__
    self.llm = self.create_llm()
  File "/home/workspace/Super_MARIO/mcts_math/solver.py", line 92, in create_llm
    engine, sampling_params = llm_engine(self.config)
  File "/home/workspace/Super_MARIO/mcts_math/llms/local_llm_engine.py", line 48, in llm_engine
    llm, sampling_params = llm_init(config)
  File "/home/workspace/Super_MARIO/mcts_math/llms/local_llm_engine.py", line 26, in llm_init
    llm = LLM(
  File "/home/workspace/vllm/vllm/entrypoints/llm.py", line 109, in __init__
    self.llm_engine = LLMEngine.from_engine_args(engine_args)
  File "/home/workspace/vllm/vllm/engine/llm_engine.py", line 145, in from_engine_args
    engine = cls(*engine_configs,
  File "/home/workspace/vllm/vllm/engine/llm_engine.py", line 102, in __init__
    self.model_executor = executor_class(model_config, cache_config,
  File "/home/workspace/vllm/vllm/executor/gpu_executor.py", line 35, in __init__
    self._init_worker()
  File "/home/workspace/vllm/vllm/executor/gpu_executor.py", line 63, in _init_worker
    self.driver_worker.load_model()
  File "/home/workspace/vllm/vllm/worker/worker.py", line 98, in load_model
    self.model_runner.load_model()
  File "/home/workspace/vllm/vllm/worker/model_runner.py", line 90, in load_model
    self.model = get_model(self.model_config,
  File "/home/workspace/vllm/vllm/model_executor/model_loader.py", line 88, in get_model
    model.load_weights(model_config.model, model_config.download_dir,
  File "/home/workspace/vllm/vllm/model_executor/models/modeling_value_head.py", line 154, in load_weights
    self.pretrained_model.load_weights(model_name_or_path, cache_dir,
  File "/home/workspace/vllm/vllm/model_executor/models/llama.py", line 399, in load_weights
    param = params_dict[name]
KeyError: 'pretrained_model.lm_head.weight'

The intermediate training files is like:

I can see the lack of config.json, generation_config.json, model.safetensors.index.json, value_head.pth.
I tried copy these files from the original ckpt but still have the same error.
And I can successfully run evaluation on both the original ckpt (added value head) and the Round3 ckpt you release on Huggingface.

Thanks for your insight question. Your code dose not process the checkpoint properly.
I have updated the implementation_details.md for this issue.
Please refer to Section Save checkpoint.
Feel free for any question. 🥳

Thanks for your explanation.
The problem is caused by I save the value head in the overall weights. Can be fixed by save the value_head.pth apart from each ckpt (before train). Also I found it can be fixed by manually split the value head from a trained ckpt (after train).
Another noteworthy aspect is that, the llama-factory-0.6.1 will add a pretrained_model. prefix to the weight keys (on my machine for unknown reason), I need to remove it to deploy the trained ckpt.

I'm working on it. Does it mean the ValueTrainer train both the policy model and value model (head) at the same time?

Yes. ValueTrainer is just what I name the Trainer for Alphamath, and it doesn't matter.
You should add + [FixValueHeadModelCallback()] in callbacks and modify V_HEAD_WEIGHTS_NAME = "value_head.pth"  in ./llmtuner/extras/constants.py.

Thank you very much for your patient guidance. I've reproduced the training stage on Round 3 data successfully.
And I got the accuracy 0.65 after running SBS(B=3) inference on the MATH testset, which is very close to the data you published.


Fixes ISS #96 - Allows versioning to be turned off and still works

Allows versioning to be turned off and still works without the libraries needing to be named with the version number in them

I tested the RefreshIG operation on cqframework/ecqm-content-r4 without the -v and dbcg/connectathon/fhir401 with -v
For ecqm-content-r4 I had to update the _refresh scripts to be compatible with this branch of the cqf-tooling. When I ran the tooling I got:
11:07:54.244 [main] WARN o.o.cqf.tooling.utilities.LogUtils - EXM124v8 could not be processed:
Resource could not be processed: EXM124v8
5 included cql Libraries not found:
FHIRHelpers-4.0.0 MISSING
Hospice-1.0.000 MISSING
AdultOutpatientEncounters-1.1.000 MISSING
MATGlobalCommonFunctions-4.0.000 MISSING
SupplementalDataElements-1.0.0 MISSING
Resource could not be processed: EXM124v8
/home/jp/repos/ecqm-content-r4/input/resources/library/home/jp/repos/ecqm-content-r4/input/resources/library-FHIR-ModelInfo-4.0.0.json (No such file or directory)
11:07:54.245 [main] WARN o.o.cqf.tooling.utilities.LogUtils -
0 Measures successfully bundled:
1 Measures refreshed, but not bundled (due to issues):
EXM124v8 REFRESHED

Note this missing /Library/ directory of the filepath, and the additional library- prefix of the resource name, and the version attached to the filename.
input/resources/library-FHIR-ModelInfo-4.0.0.json
The resources themselves had urls and references without versions in the Id, which looks right to me.
On DBCG dbcg/connectathon/fhir401 I had numerous warnings that were similar:
Resource could not be processed: MATGlobalCommonFunctions-5.0.000                  /home/jp/repos/connectathon/fhir401/input/resources/Library/home/jp/repos/connectathon/fhir401/input/resources/Library-MATGlobalCommonFunctions-5.0.000.json (No such file or directory)

These are also missing the /Library/ directory, and the resource still has Library- prefix.
The resources themselves look correct to me.

How are you testing this then? I just have the code opened in my IDE (Eclipse) and run it using -RefreshIG -ini="/Users/mholck/Development/CQF_Ruler/connectathon/fhir401/ig.ini" -t -d -p -v and all 15 measures bundle fine in connectathon fhir401
and run it with -RefreshIG -ini="/Users/mholck/Development/ecqm-content-r4/ig.ini" -t -d -p
and the EXM124v8 bundles fine

@mholck and I jumped on a video chat and chased it down to a case-sensitivity issue. My machine (Ubuntu 20.10) is case sensitive while mholk's (MacOS) is not. mholck is investigating options.


Fix Vulkan renderer on wayland

This fixes the outstanding problems mentioned in #2416. I do not really know C++ so tips how to determine wl_surface dynamically are welcome.
In order to test this, --with-sdl --with-wayland needs to be added to makefile line 116.

To be precise: we need a way of passing the wmi.info.wl.surface which is being defined in entry_sdl.cpp to renderer_vk.cpp. I do not know how to do that, the existing structures appear to only be able to pass display and window handles but not the surface one.

Would something like this be acceptable?

Turns out it was simpler than originally thought.

Much better... what is setting this WL_EGL_PLATFORM?

It is set by genie.lua:
https://github.com/bkaradzic/bgfx/blob/8b6a6bdf0eae130a62f0af003282bf042ed97e7b/scripts/genie.lua#L207-209

@belegdol Check this: https://github.com/libsdl-org/SDL/pull/9345 (intentionally in code quotes to not notify the issue, since it has nothing to do with bgfx, just notifying you about the issue).

@belegdol Check this: https://github.com/libsdl-org/SDL/pull/9345 (intentionally in code quotes to not notify the issue, since it has nothing to do with bgfx, just notifying you about the issue).

Thanks for the info, this is a bit disappointing. In any case, slow is better than crashing in my opinion. Additionally, for cases like mame - which motivated me to submit this PR in the first place - getting every last bit of GPU performance is not that critical. mame runs fast enough on my machines at least.

In any case, slow is better than crashing in my opinion.

Yes. Anyhow, the point of notifying you is just to keep you informed. No action needed on bgfx.


php: command not found

Hi there,
I installed snowcord but unfortunately I am getting the following error when using it:
Code 127: /Users/fs/Library/Caches/com.runningwithcrayons.Alfred/Workflow Scripts/2BC30EB7-4AA4-446F-B50E-858C993FDD68: line 2: php: command not found

Do you have an idea why that is happening?
Appreciate your help!

I'm assuming this is with the new v1.0.1 released last night (and not 1.0.0)?
When Snowcord runs it uses bash to execute the core php file (Alfred can store scripts directly in the workflow, but this means bundling them into Info.plist rather than keeping them file based, which is simpler to maintain), but in your case bash can't find the php binary. Previously (in 1.0.0) I'd sourced ~/.bashrc to get the Homebrew environment path, which is quite a bit of a legacy (it used to be created by Homebrew but no longer as the default shell changed from bash to zsh back in MacOS Catalina), but in any case it didn't matter if it failed because stock php was still in MacOS ... unless you were on Monterey.
Since last night's 1.0.1 update, Snowcord will check whether /opt/homebrew/bin/brew exists, and if so source the environment from /opt/homebrew/bin/brew shellenv (via same method in Whencord 1.0.1, which I'm glad to hear is working for you). This is so that for pre-Monterey users, stock php will be used as a fallback, while any version installed with Homebrew can take precedence. Monterey should also now run Snowcord without issue, providing PHP is installed via Homebrew.
I was unable to replicate this on my fresh MacOS Monterey demo install. Do let me know if you're running 1.0.1

@fabston Do let me know if you're still experiencing this issue, or whether it was resolved by 1.0.1.
I'll leave this open a couple more days either way.

I presume this was resolve so I'm closing this issue. Do feel free to reply if you're still experiencing the problem.


Make the README doctest work on new rust and stable

Closes #5

The clippy failures from this are not because of my changes at all, rather, they are from a rust update and should be fixed separately.

I fixed them anyway.

Great changes, thanks for making a PR!


[Feature] Reword 'TestsConfigDeprecation' message to avoid confusion around deprecation timeline (not planned)

Is this your first time submitting a feature request?

[X] I have read the expectations for open source contributors
[X] I have searched the existing issues, and I could not find an existing issue for this feature
[X] I am requesting a straightforward extension of existing dbt functionality, rather than a Big Idea better suited to a discussion

Describe the feature
I propose that we reword this deprecation warning in order to:

Explain the rationale: with the introduction of "unit tests," we are differentiating these from "data tests"
Make it clear that we are unlikely to remove support for the old nomenclature (if ever)
Document how users can silence it

At the risk of a very wordy deprecation warning, it could be a slight language tweak and an update to the linked documentation.
Before:
09:19:21  [WARNING]: Deprecated functionality
The `tests` config has been renamed to `data_tests`. Please see
https://docs.getdbt.com/docs/build/data-tests#new-data_tests-syntax for more
information.

After:
09:19:21  [WARNING]: dbt now supports 'unit_tests'. To disambiguate from traditional 'data_tests',
dbt will encourage you to rename your 'tests' config to 'data_tests'. Please see
https://docs.getdbt.com/docs/build/data-tests#new-data_tests-syntax for more
information, or https://docs.getdbt.com/reference/global-configs/warnings to silence this warning.

Describe alternatives you've considered
Not doing this
Who will this benefit?
Users who are confused about:

seeing this deprecation warning
reading our publicly stated commitment to ongoing compatibility, such that dbt Core users & dbt Cloud customers should feel comfortable upgrading to / keeping on latest version

Are you interested in contributing this feature?
yes!
Anything else?
No response

@jtcohen6 we discussed at refinement, the updated first sentence seems a bit complex. Can we make it simpler?


libvirt: fix default IP logic

If we have a default IP address the logic that will calculate the IP based on the libvirt network will never be executed.

Does this also mean we can remove the line in the doc: https://github.com/confidential-containers/cloud-api-adaptor/blob/fd1cc099903328065aea6ebf91ea0ca6807b391e/src/cloud-api-adaptor/libvirt/README.md?plain=1#L99 that sets it and let the code figure it out itself?

Does this also mean we can remove the line in the doc:
https://github.com/confidential-containers/cloud-api-adaptor/blob/fd1cc099903328065aea6ebf91ea0ca6807b391e/src/cloud-api-adaptor/libvirt/README.md?plain=1#L99
that sets it and let the code figure it out itself?

Yes, just fixed with the force-push.

re-running the tests


Fix for xcodebuild tool compilation error on version 8.1(8B62)

Description
With latest changes introduced around wrapping constant names into external files, Bugsnag library stopped compiling on old Xcode versions (I was using 8.1(8B62)). We still use old Xcode version to run Appium tests, as there is some migration needed to get test running on Xcode 9 and we are facing other issues, like slow and unstable builds.
We only need to remove the unneeded wrapper string that is initialised with another non-constant at compile time string and then everything works fine.

The same problem happens on Circle CI, please merge this PR.

Merged and released in v5.13.3 - thanks for the contribution @idcuesta!

Thank you for ultra fast response @fractalwrench 👍


clarify definition of content 1..1

close #110

@lukeaduncan I think we agreed to these changes... so I think I just want another set of eyes to confirm I did what we agreed to do.

no, short, definition, and comment are all independent.


add GIT_REMOTE_ORIGIN_URL to runner.py and update test case

Fixes #852

Looks good! 👌

thanks a lot 🙏


Eclipse deadlocks and hangs when DBeaver extension is installed

System information:

Operating system (distribution) and version: Windows 10 Pro x64
DBeaver version: Dbeaver 6.3.4 installed on Eclipse IDE Version: 2019-12 (4.14.0) Build id: 20191212-1212
Additional extensions: see attached eclipse configuration for other installed plugins if they could interfere

Connection specification:

Database name and version - not required to reproduce
Driver name - not required to reproduce
Do you use tunnels or proxies (SSH, SOCKS, etc)? - not required to reproduce

Describe the problem you're observing:
Eclipse operations such as build and clean start hanging when
Steps to reproduce, if exist:
Start eclipse with DBeaver installed. Create some maven projects if workspace is empty. Clean all projects (several times if not reproducible right away). Eventually "Project '' sync job." should appear. Cleaning or building will hang and you won't be able to cancel it. Uninstall DBeaver. Observe cleaning and building no longer hangs.
Unfortunately I cannot share my workspace and don't have time at the moment to experiment and create minimal one to reproduce.
Include any warning/errors/backtraces from the logs
See attached thread dump (with preceding logs) and eclipse configuration.
eclipse-configuration.txt
eclipse-thread-dump.txt
At the moment I either have to stop using DBeaver altogether or create a separate eclipse and separate empty workspace for it.
Additional note:
This might be related to the issue #7898 or might not. Since it doesn't hangs for me at startup and since all the threads involved seems to be waiting I believe it's actually a deadlock and might be a different issue from #7898.

Thanks for the bug report.
It is a bug in threads sync.

verified


libinput binaries are non-functional (missing python/evdev?)

Issue description

Add libinput to your environment packages.

sudo libinput measure touchpad-pressure:

Error: No module named 'evdev'
One or more python modules are missing. Please install those modules and re-run this tool.

I'm really not good with python, especially python+nixpkgs. Any suggestions, I can try to fix it?

I guess we need to use python3.withPackages (pkgs: with pkgs; [ evdev ]). It will not work well until https://github.com/NixOS/nixpkgs/pull/46020 is merged though, since meson propagates python which will take precedence.

Any news about that issue? Or at least is there any way to temporary fix the issue locally? I tried:
[me@nixos:~]$ nix-shell -p libinput -p libevdev -p python3 "python3.withPackages(ps: with ps; [evdev])"

[nix-shell:~]$ sudo libinput measure touchpad-pressure
Error: No module named 'libevdev'
One or more python modules are missing. Please install those modules and re-run this tool.

but it does not work...

I opened https://github.com/NixOS/nixpkgs/pull/92715, however, it bloats libinput maybe too much.

Thanks a lot ! Well I think that it's better to have bigger working packages rather than small buggy ones…
I'll test it soon, but out of curiosity, is there some general methods to force temporary an "unpure" fetch of dependencies, in case I'm having similar issues latter on?
Thanks!

I am not sure what you mean by "unpure" fetch of dependencies. Do you want to replace libinput on your system with the fixed one? In this case the tools do not need to be installed so you should be able to run it using nix-shell from this branch. But in general, there is system.replaceRuntimeDependencies NixOS option.

Interesting option, thanks!
But it's not really what I was asking for, it's more like, imagine that I see that one program/library used by some packages are missing (like here), is there a way to automatically add the program/libraries into the PATH/LD_LIBRARY variables open in the current nix-shell, so that all the program I use automatically have access to that library? For example here I tried to solve the problem with:
nix-shell -p libinput -p libevdev -p python3 "python3.withPackages(ps: with ps; [libevdev])"

but I guess that the libinput program has a wrapper script that removes the libevdev library, and makes it unaccessible to libinput.

I would say here your problem is you are defining python twice, and the first one without packages is first in path. Also nix-shell does not actually set LD_LIBRARY_PATH so dlopen will not see it. The following works in this case.
nix-shell -I nixpkgs=$PWD -p libinput "python3.withPackages(ps: with ps; [libevdev pyudev])" --run "sudo env LD_LIBRARY_PATH=$(nix-build -A libevdev --no-out-link)/lib libinput measure touchpad-pressure"

Of course that is only because https://github.com/NixOS/nixpkgs/commit/de14f0c6e1247aa48b0d77c4a3390a61e020bebf removed Python from buildInputs, so the shebang is /usr/bin/env python3. If it were processed by patchShebangsAuto, you would need to muck with PYTHONPATH:
nix-shell -I nixpkgs=$PWD -p libinput python3 python3.pkgs.libevdev python3.pkgs.pyudev --run "sudo --preserve-env=PYTHONPATH env LD_LIBRARY_PATH="$(nix-build -A libevdev --no-out-link)/lib" libinput measure touchpad-pressure"

And if some wrapper actually sealed the environment variable (usually wrappers just  --prefix them but, ocassionally, they use --set) you would have no other choice than modify the package – either using overrideAttrs or directly editing the expression in your copy of nixpkgs. The latter is what I did when testing the fix, since it is more convenient than trying to add the dependencies as command line arguments.

This was fixed by #92715.


Revert "Increase Virtualbox disk image size"

Reverts NixOS/nixpkgs#46649
and unbreak the build of nixos.ova.x86_64-linux ( https://hydra.nixos.org/build/82516491 )

Uh oh. Why would hydra spend more time on the bigger (sparse) image? Are we sure this wasn't just a sporadic timeout? (I would really like to see the virtualbox image have more headroom, which is now unfortunately reverted.)

We would like it too...
It's highly possible the Hydra failure was just a transient error, but at the time the revert was the right thing to do in order to unbreak things.
For the momnt I haven't come around to try and build locally like it was suggested in #46649 ...
I think we should maybe start with a VHD/VDI disk image that could easily be resized by VirtualBox, rather than a fixed-size raw image inside of a VMDK wrapper.


Makefile colorizing improvement: colorize at the beginning of line, handling the '' symbol and other.

Pull request is created into TextMate repository as well: https://github.com/textmate/make.tmbundle/pull/14
1). Colorize when the expression at the beginning of line.
2). Handle '\' at the end of prerequisites (the next line should be colorized as a continuation of previous).
3). Colorize (origin|flavor).
4). Fix colorizing of built-in which stands after a common variable.

This seems like a small (but important) contribution, so no Contribution License Agreement is required at this point. We will now review your pull request.
Thanks,
Microsoft Pull Request Bot

As I understand the test should be changed for updated colorizing, right?
Could anybody help to fix the test? Thank you!

Sorry for closing, I re-created here: https://github.com/Microsoft/vscode/pull/27293
Reason: I tested more and found some issues. Improved.


toJSON function

Hello!
Does tcomb library have support for toJSON function? opposite to fromJSON?
I need it for converting Date object to the String.
Thank you!

Hi,
not sure why you would need that, toJSON is already supported by JSON.stringify

You are right. I was confused.
Thank you for the quick answer!


cloudformation/parsing.py has an incomplete UNDOCUMENTED_NAME_TYPE_MAP

Issue
cloudformation/parsing.py wisely has an UNDOCUMENTED_NAME_TYPE_MAP because the name type references in the Amazon documentation are incomplete. However, there are additional resource types that should be added. For my purposes in particular, I would like to add
{
    "AWS::Batch::ComputeEnvironment": "ComputeEnvironmentName",
    "AWS::Batch::JobDefinition": "JobDefinitionName",
    "AWS::Batch::JobQueue": "JobQueueName",
    "AWS::EC2::LaunchTemplate": "LaunchTemplateName",
}

and I will submit a PR to that effect.
But, combing through the cloudformation documentation, I noticed that the following resource types could also be added:
{
    "AWS::AccessAnalyzer::Analyzer": "AnalyzerName",
    "AWS::AmazonMQ::Broker": "BrokerName",
    "AWS::AmazonMQ::Configuration": "Name",
    "AWS::Amplify::App": "Name",
    "AWS::Amplify::Branch": "BranchName",
    "AWS::Amplify::Domain": "DomainName",
    "AWS::ApiGateway::Authorizer": "Name",
    "AWS::ApiGateway::DomainName": "DomainName",
    "AWS::ApiGateway::RequestValidator": "Name",
    "AWS::ApiGateway::RestApi": "Name",
    "AWS::ApiGateway::Stage": "StageName",
    "AWS::ApiGateway::UsagePlan": "UsagePlanName",
    "AWS::ApiGateway::VpcLink": "Name",
    "AWS::ApiGatewayV2::Api": "Name",
    "AWS::ApiGatewayV2::Authorizer": "Name",
    "AWS::ApiGatewayV2::DomainName": "DomainName",
    "AWS::ApiGatewayV2::Model": "Name",
    "AWS::ApiGatewayV2::Stage": "StageName",
    "AWS::ApiGatewayV2::VpcLink": "Name",
    "AWS::AppConfig::Application": "Name",
    "AWS::AppConfig::ConfigurationProfile": "Name",
    "AWS::AppConfig::DeploymentStrategy": "Name",
    "AWS::AppConfig::Environment": "Name",
    "AWS::AppMesh::Mesh": "MeshName",
    "AWS::AppMesh::Route": "RouteName",
    "AWS::AppMesh::VirtualNode": "VirtualNodeName",
    "AWS::AppMesh::VirtualRouter": "VirtualRouterName",
    "AWS::AppMesh::VirtualService": "VirtualServiceName",
    "AWS::AppStream::Fleet": "Name",
    "AWS::AppStream::ImageBuilder": "Name",
    "AWS::AppStream::Stack": "Name",
    "AWS::AppSync::DataSource": "Name",
    "AWS::AppSync::FunctionConfiguration": "Name",
    "AWS::AppSync::GraphQLApi": "Name",
    "AWS::ApplicationAutoScaling::ScalingPolicy": "PolicyName",
    "AWS::Athena::DataCatalog": "Name",
    "AWS::Athena::NamedQuery": "Name",
    "AWS::Athena::WorkGroup": "Name",
    "AWS::Backup::BackupVault": "BackupVaultName",
    "AWS::CE::CostCategory": "Name",
    "AWS::Cassandra::Keyspace": "KeyspaceName",
    "AWS::Cassandra::Table": "TableName",
    "AWS::Chatbot::SlackChannelConfiguration": "ConfigurationName",
    "AWS::Cloud9::EnvironmentEC2": "Name",
    "AWS::CloudFormation::Macro": "Name",
    "AWS::CloudTrail::Trail": "TrailName",
    "AWS::CloudWatch::CompositeAlarm": "AlarmName",
    "AWS::CloudWatch::Dashboard": "DashboardName",
    "AWS::CloudWatch::InsightRule": "RuleName",
    "AWS::CodeBuild::Project": "Name",
    "AWS::CodeBuild::ReportGroup": "Name",
    "AWS::CodeCommit::Repository": "RepositoryName",
    "AWS::CodeGuruProfiler::ProfilingGroup": "ProfilingGroupName",
    "AWS::CodePipeline::Pipeline": "Name",
    "AWS::CodePipeline::Webhook": "Name",
    "AWS::CodeStarConnections::Connection": "ConnectionName",
    "AWS::CodeStarNotifications::NotificationRule": "Name",
    "AWS::Cognito::UserPool": "UserPoolName",
    "AWS::Cognito::UserPoolClient": "ClientName",
    "AWS::Cognito::UserPoolGroup": "GroupName",
    "AWS::Cognito::UserPoolIdentityProvider": "ProviderName",
    "AWS::Cognito::UserPoolResourceServer": "Name",
    "AWS::Config::ConfigurationAggregator": "ConfigurationAggregatorName",
    "AWS::Config::ConformancePack": "ConformancePackName",
    "AWS::Config::OrganizationConfigRule": "OrganizationConfigRuleName",
    "AWS::Config::OrganizationConformancePack": "OrganizationConformancePackName",
    "AWS::Events::EventBus": "Name",
    "AWS::Logs::Destination": "DestinationName",
    "AWS::Logs::LogStream": "LogStreamName",
    "AWS::ServiceDiscovery::HttpNamespace": "Name",
    "AWS::ServiceDiscovery::PrivateDnsNamespace": "Name",
    "AWS::ServiceDiscovery::PublicDnsNamespace": "Name",
    "AWS::ServiceDiscovery::Service": "Name",
}

...and probably much more. I just stopped alphabetically after services that start with "C" because I was tired and also unfamiliar with those services. So the dict could wind up being pretty long. In addition to referencing my PR to add the batch services, maybe this issue could spur comments from the core devs about how to handle the large number of custom name types. I'd be happy to submit a PR for the additional service types also but don't want to make it too unwieldy to maintain.
Versions
pip list | grep oto returns
boto               2.49.0
boto3              1.14.20
botocore           1.17.20
moto               1.3.15.dev959

Hi @richford, thanks for raising this. The full list would become quite wieldy indeed, so I don't think listing everything in one place is the way to go.
IMO, in order to keep this maintainable, the responsibility should be decentralized, and this user-friendly identifier should be supplied by the model itself.
Most Models already have a physical_resource_id to identify them in CloudFormation. We could simply extend this, and also add a logical_resource_id to each Model that would return the appropriate attribute.
Going one step further, we might not eve need the mapping from AWS::AccessAnalyzer::Analyzer -> moto.access.model. Have each BaseModel supply the name how it is known in CF, and we can build the list of supported models at runtime.
@spulec Any ideas on this?

I agree that moving this (and more) into the service models feels like a more maintainable approach long-term.

That makes sense. Thanks @bblommers and @spulec for the input. It looks like we should then close #3128 without merging and address this issue as you prescribed.
Given my limited knowledge of how moto works internally, the recommended approach is a bit over my head and I'll need some suggestions and pointers to get started. Happy to help but I just want to set expectations about how long it'll take me.

Hi @richford, see the attached PR - hopefully that makes it clear what I had in mind. Feel free to push to that branch, or copy it into your own branch, whatever is easier.

This is now part of moto >= 1.3.15.dev1015


⚠ Spryr has degraded performance

In 1f9b107, Spryr (https://spryr.com) experienced degraded performance:

HTTP code: 200
Response time: 4370 ms

Resolved: Spryr performance has improved in 968a792 after 7 minutes.


Cdn review comments that need service team confirmation

Why is this provisioningState a string instead of enum? We saw that some of the provisioningState definitions are enum but others are string, so I'm wondering if we can unify the type.
Is this validationData a BinaryData?
Some models seem to have the similar even same definitions. One example is operator, you can see ClientPortOperator, CookiesOperator, HostNameOperator and other operators almost share the same definition. The question here is why we have to repeat the definition multiple times. Is it possible to define a common extensible enum in this scenario?
Can we change the type of unit to extensible enum so it can keep consistency with UsageUnit in afdx?
Is the groupId in SharedPrivateLinkResourceProperties a ResourceIdentifier like /subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/{resourceProviderNamespace}/{resourceType}/{resourceName}? Same question in keyId.
Why is this called AfdMinimumTlsVersion instead of AfdTlsVersion? What's the meaning of Minimum? Same question in cdn MinimumTlsVersion.
Why all these operations have the same description?

https://github.com/Azure/azure-rest-api-specs/blob/main/specification/cdn/resource-manager/Microsoft.Cdn/stable/2021-06-01/afdx.json#L90
https://github.com/Azure/azure-rest-api-specs/blob/main/specification/cdn/resource-manager/Microsoft.Cdn/stable/2021-06-01/afdx.json#L929
https://github.com/Azure/azure-rest-api-specs/blob/main/specification/cdn/resource-manager/Microsoft.Cdn/stable/2021-06-01/afdx.json#L1353
https://github.com/Azure/azure-rest-api-specs/blob/main/specification/cdn/resource-manager/Microsoft.Cdn/stable/2021-06-01/afdx.json#L2308

Label prediction was below confidence level 0.6 for Model:ServiceLabels: 'Compute:0.14346664,Tables:0.09164508,ARM:0.0911659'

Some operators have different definitions, also different operators may extend different property
AfdMinimumTlsVersion means the minimum TLS version to support, all TLS versions greater or equal to AfdMinimumTlsVersion are supported

For question 5:

Is the groupId in SharedPrivateLinkResourceProperties a ResourceIdentifier like /subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/{resourceProviderNamespace}/{resourceType}/{resourceName}? Same question in keyId.

Both properties are not Resource Identifiers, groupId is a concept used by private link, it means the ID of the group obtained from the remote resource that this private endpoint should connect to.  The value  is like:
 az network private-link-resource list -g bogroup -n boplstest --type Microsoft.Storage/storageAccounts --query "[*].properties.groupId"
Resource ID will be ignored since other three arguments have been provided.
[
  "blob",
  "blob_secondary",
  "table",
  "table_secondary",
  "queue",
  "queue_secondary",
  "file",
  "web",
  "web_secondary",
  "dfs",
  "dfs_secondary"
]

The keyId is not referring any azure resource.

For question 2:

Is this validationData a BinaryData?

It is just plain string.

For question 1:

Why is this provisioningState a string instead of enum? We saw that some of the provisioningState definitions are enum but others are string, so I'm wondering if we can unify the type.

Yes, we should unify the type.
For question 4

Can we change the type of unit to extensible enum so it can keep consistency with UsageUnit in afdx?

Yes, we should reuse the model.
For question 7

Why all these operations have the same description?

Those are copy typos, we should change the description accordingly.

Thanks @ChenglongLiu and @t-bzhan for the update, it helps a lot!

@Yao725 Question 7 has been fixed

Question 1 and 4 have been fixed

Close this one as the comments have been resolved and we have released the stable version for Cdn.


Flatpak config files to run in gnome runtime

Is your feature request related to a problem? Please describe.
I just published 0.16 branch which should work in gnome runtime. It upgrades gtk-rs crates to 0.16 and bumps webkit2gtk version to 4.1 so we can use libsoup3. This should help fix #717
Describe the solution you'd like
Add necessary config files to build flatpak application. It should use gnome runtime 43 with rust extension.
If possible, please also write down steps to build the application.
Describe alternatives you've considered
No, this is the only way to keep my sanity.
Would you assign yourself to implement this feature?

[x] Yes, but I'm not familiar with flatpak. I hope anyone already understand it can help me.
[ ] No

Additional context

Just for reference, @Beanow's experiments on this:
https://github.com/tauri-apps/tauri/issues/3619
https://github.com/tauri-apps/tauri/discussions/4426
https://github.com/Beanow/hi-flatpak
(p.s. i can also spend some/much time on flatpaks now as i have to pause development on the new appimages for a bit because i apparently can't seem to fix a blocking appimage-builder issue.)

with rust extension.

Note, this extension should only be necessary during build.
So it's Gnome SDK + Rust extention (+ Node extension) to build.
And only Gnome runtime to run.

I think (a very WIP) config was in:
https://github.com/Beanow/tauri/tree/feat/bundler/flatpak/tooling/bundler/src/bundle/linux
https://github.com/Beanow/tauri/blob/feat/bundler/flatpak/tooling/bundler/src/bundle/linux/flatpak/manifest-template

I don't have a share-able file yet but the 0.16 branches seem to work correctly in flatpak apps. I'll try to clean it up and post it today when i'm back home.
For testing i build the app outside of the sdk and used that bundled binary as a source instead (so my manifest may not be that helpful in the long run).
But imho i think we should start with that approach first (re-use the .deb, or the binary and icons etc directly), make the apps work correctly, look at all the portals stuff, and then later in another iteration look at building the app inside the sdk. This way we could get it faster to users, and it's potentially easier to use/integrate into existing pipelines, and users don't have to build the app twice (that one is a "maybe").

Sorry for the delay, here's a really simple config which expects you to build the wry binary outside of the SDK for now, since all the actual tooling development will be in Tauri anyway i think this should be enough for wry.
fp.zip
This zip file contains the config, the .desktop file, and 2 icons (i didn't really test the icons much but the paths and config should be correct but are not displayed)
steps to run

sudo apt install flatpak flatpak-builder
build one of the examples and copy the example binary into some dir, or cd into the target/debug|release/examples dir
if you want to test tray icons: git clone https://github.com/flathub/shared-modules in the dir mentioned above
if you don't want to test tray icons you can remove the libappindicator line from the config if you don't wanna clone the repo
flatpak-builder --user --install --force-clean build-dir org.tauri.wry-test.json
flatpak run org.tauri.wry-test

I do tend to change the config from json to yaml so that we can add comments, i just copy pasted that from rustdesk tbh


Remove mention of offer once an offer has been accepted

Context
Tiny content bug – if a candidate views their application after accepting an offer we still say References to be requested if you accept an offer. This doesn't make sense.
Changes proposed in this pull request
Conditionally change the title depending on application status.

Before
After

@JR-G For the upcoming cycle onwards, I think we could just remove references completely from the application view (after accepting an offer) as they can see a better view of references within the dashboard, and the references aren't really part of the application any more? cc @johndoates

@frankieroberto i'll merge this for now and then we can discuss this separately with john and I'm happy to make the amendments that will follow!


Create design documentation to differentiate badge and tag

General Support Request

Support request

Designers are confused about what the difference is between badge and tag.
Possible Solution

Create documentation to explain how badge and tag will be separate on the design side vs categorized under badge on the engineering side.

https://www.figma.com/file/mi7SCkpWH8lV3hv8SISZoc/Badge?node-id=0%3A810
Completed guidelines. Will share this during UI sync and design fair.

@leeejune @blackfalcon @braven112 This one hasn't changed in 17 days. What do we still need to do here?

@jason-capsule42 it's waiting on me.

@leeejune has final say in the design aspect of this work.


Bloom explosion : )

Enough time : )
This does not really affect me.

This is probably due to a bug in the sampling/evaluating of the Beckmannn BSDF model; which ultimately results in NaNs. I will look into it later.

This is resolved now that we have new material types.


It appears Layout/HashAlignment don't like anonymous arguments

Anonymous arguments:
https://rubyreferences.github.io/rubychanges/3.2.html#anonymous-arguments-passing-improvements

Expected behavior
My code which looks like below caused a crash. And I didn't expect that. This is valid ruby so I rubocop should accept it too.
  def insert_invoice(*, **)
    FactoryBot.create(
      :invoice, *,
      supplier_bban: supplier1_bank_account1.bban,
      supplier_swift: "SHENOP94",
      supplier_unit: supplier_unit1,
      supplier_country_code: "NO",
      customer_unit: unit,
      payable_amount_currency: nok,
      **
    )
  end

Actual behavior

$ be rubocop --debug spec/views/payments/new_spec.rb --only Layout/HashAlignment                                                                               17:46:23
For /Users/simon/dev/work/dodo/fakturabank/repo: configuration from /Users/simon/dev/work/dodo/fakturabank/repo/.rubocop.yml
configuration from /Users/simon/.asdf/installs/ruby/3.2.1/lib/ruby/gems/3.2.0/gems/rubocop-capybara-2.17.1/config/default.yml
Default configuration from /Users/simon/.asdf/installs/ruby/3.2.1/lib/ruby/gems/3.2.0/gems/rubocop-1.48.1/config/default.yml
configuration from /Users/simon/.asdf/installs/ruby/3.2.1/lib/ruby/gems/3.2.0/gems/rubocop-capybara-2.17.1/lib/../config/default.yml
configuration from /Users/simon/.asdf/installs/ruby/3.2.1/lib/ruby/gems/3.2.0/gems/rubocop-rspec-2.19.0/config/default.yml
configuration from /Users/simon/.asdf/installs/ruby/3.2.1/lib/ruby/gems/3.2.0/gems/rubocop-rspec-2.19.0/config/default.yml
configuration from /Users/simon/.asdf/installs/ruby/3.2.1/lib/ruby/gems/3.2.0/gems/rubocop-performance-1.16.0/config/default.yml
configuration from /Users/simon/.asdf/installs/ruby/3.2.1/lib/ruby/gems/3.2.0/gems/rubocop-performance-1.16.0/config/default.yml
configuration from /Users/simon/.asdf/installs/ruby/3.2.1/lib/ruby/gems/3.2.0/gems/rubocop-rails-2.18.0/config/default.yml
configuration from /Users/simon/.asdf/installs/ruby/3.2.1/lib/ruby/gems/3.2.0/gems/rubocop-rails-2.18.0/config/default.yml
Inheriting configuration from /Users/simon/dev/work/dodo/fakturabank/repo/.rubocop_dodo.yml
Inheriting configuration from /Users/simon/dev/work/dodo/fakturabank/repo/.rubocop_todo.yml
.rubocop.yml: Layout/LineLength:Max overrides the same parameter in .rubocop_dodo.yml
.rubocop.yml: Metrics/BlockLength:Exclude overrides the same parameter in .rubocop_dodo.yml
Use parallel by default.
Skipping parallel inspection: only a single file needs inspection
Inspecting 1 file
Scanning /Users/simon/dev/work/dodo/fakturabank/repo/spec/views/payments/new_spec.rb
An error occurred while Layout/HashAlignment cop was inspecting /Users/simon/dev/work/dodo/fakturabank/repo/spec/views/payments/new_spec.rb:74:6.
undefined method `hash_rocket?' for s(:forwarded_kwrestarg):RuboCop::AST::Node
/Users/simon/.asdf/installs/ruby/3.2.1/lib/ruby/gems/3.2.0/gems/rubocop-1.48.1/lib/rubocop/cop/layout/hash_alignment.rb:303:in `alignment_for'
/Users/simon/.asdf/installs/ruby/3.2.1/lib/ruby/gems/3.2.0/gems/rubocop-1.48.1/lib/rubocop/cop/layout/hash_alignment.rb:256:in `block in check_pairs'
/Users/simon/.asdf/installs/ruby/3.2.1/lib/ruby/gems/3.2.0/gems/rubocop-1.48.1/lib/rubocop/cop/layout/hash_alignment.rb:255:in `each'
/Users/simon/.asdf/installs/ruby/3.2.1/lib/ruby/gems/3.2.0/gems/rubocop-1.48.1/lib/rubocop/cop/layout/hash_alignment.rb:255:in `check_pairs'
/Users/simon/.asdf/installs/ruby/3.2.1/lib/ruby/gems/3.2.0/gems/rubocop-1.48.1/lib/rubocop/cop/layout/hash_alignment.rb:215:in `on_hash'
/Users/simon/.asdf/installs/ruby/3.2.1/lib/ruby/gems/3.2.0/gems/rubocop-1.48.1/lib/rubocop/cop/commissioner.rb:107:in `public_send'
/Users/simon/.asdf/installs/ruby/3.2.1/lib/ruby/gems/3.2.0/gems/rubocop-1.48.1/lib/rubocop/cop/commissioner.rb:107:in `block (2 levels) in trigger_responding_cops'
/Users/simon/.asdf/installs/ruby/3.2.1/lib/ruby/gems/3.2.0/gems/rubocop-1.48.1/lib/rubocop/cop/commissioner.rb:171:in `with_cop_error_handling'
/Users/simon/.asdf/installs/ruby/3.2.1/lib/ruby/gems/3.2.0/gems/rubocop-1.48.1/lib/rubocop/cop/commissioner.rb:106:in `block in trigger_responding_cops'
/Users/simon/.asdf/installs/ruby/3.2.1/lib/ruby/gems/3.2.0/gems/rubocop-1.48.1/lib/rubocop/cop/commissioner.rb:105:in `each'
/Users/simon/.asdf/installs/ruby/3.2.1/lib/ruby/gems/3.2.0/gems/rubocop-1.48.1/lib/rubocop/cop/commissioner.rb:105:in `trigger_responding_cops'
/Users/simon/.asdf/installs/ruby/3.2.1/lib/ruby/gems/3.2.0/gems/rubocop-1.48.1/lib/rubocop/cop/commissioner.rb:69:in `on_hash'
/Users/simon/.asdf/installs/ruby/3.2.1/lib/ruby/gems/3.2.0/gems/rubocop-ast-1.27.0/lib/rubocop/ast/traversal.rb:159:in `block in on_send'
/Users/simon/.asdf/installs/ruby/3.2.1/lib/ruby/gems/3.2.0/gems/rubocop-ast-1.27.0/lib/rubocop/ast/traversal.rb:156:in `each'
/Users/simon/.asdf/installs/ruby/3.2.1/lib/ruby/gems/3.2.0/gems/rubocop-ast-1.27.0/lib/rubocop/ast/traversal.rb:156:in `each_with_index'
/Users/simon/.asdf/installs/ruby/3.2.1/lib/ruby/gems/3.2.0/gems/rubocop-ast-1.27.0/lib/rubocop/ast/traversal.rb:156:in `on_send'
/Users/simon/.asdf/installs/ruby/3.2.1/lib/ruby/gems/3.2.0/gems/rubocop-1.48.1/lib/rubocop/cop/commissioner.rb:71:in `on_send'
/Users/simon/.asdf/installs/ruby/3.2.1/lib/ruby/gems/3.2.0/gems/rubocop-ast-1.27.0/lib/rubocop/ast/traversal.rb:154:in `on_def'
/Users/simon/.asdf/installs/ruby/3.2.1/lib/ruby/gems/3.2.0/gems/rubocop-1.48.1/lib/rubocop/cop/commissioner.rb:71:in `on_def'
/Users/simon/.asdf/installs/ruby/3.2.1/lib/ruby/gems/3.2.0/gems/rubocop-ast-1.27.0/lib/rubocop/ast/traversal.rb:137:in `block in on_dstr'
/Users/simon/.asdf/installs/ruby/3.2.1/lib/ruby/gems/3.2.0/gems/rubocop-ast-1.27.0/lib/rubocop/ast/traversal.rb:137:in `each'
/Users/simon/.asdf/installs/ruby/3.2.1/lib/ruby/gems/3.2.0/gems/rubocop-ast-1.27.0/lib/rubocop/ast/traversal.rb:137:in `on_dstr'
/Users/simon/.asdf/installs/ruby/3.2.1/lib/ruby/gems/3.2.0/gems/rubocop-1.48.1/lib/rubocop/cop/commissioner.rb:71:in `on_begin'
/Users/simon/.asdf/installs/ruby/3.2.1/lib/ruby/gems/3.2.0/gems/rubocop-ast-1.27.0/lib/rubocop/ast/traversal.rb:158:in `on_block'
/Users/simon/.asdf/installs/ruby/3.2.1/lib/ruby/gems/3.2.0/gems/rubocop-1.48.1/lib/rubocop/cop/commissioner.rb:71:in `on_block'
/Users/simon/.asdf/installs/ruby/3.2.1/lib/ruby/gems/3.2.0/gems/rubocop-ast-1.27.0/lib/rubocop/ast/traversal.rb:137:in `block in on_dstr'
/Users/simon/.asdf/installs/ruby/3.2.1/lib/ruby/gems/3.2.0/gems/rubocop-ast-1.27.0/lib/rubocop/ast/traversal.rb:137:in `each'
/Users/simon/.asdf/installs/ruby/3.2.1/lib/ruby/gems/3.2.0/gems/rubocop-ast-1.27.0/lib/rubocop/ast/traversal.rb:137:in `on_dstr'
/Users/simon/.asdf/installs/ruby/3.2.1/lib/ruby/gems/3.2.0/gems/rubocop-1.48.1/lib/rubocop/cop/commissioner.rb:71:in `on_begin'
/Users/simon/.asdf/installs/ruby/3.2.1/lib/ruby/gems/3.2.0/gems/rubocop-ast-1.27.0/lib/rubocop/ast/traversal.rb:20:in `walk'
/Users/simon/.asdf/installs/ruby/3.2.1/lib/ruby/gems/3.2.0/gems/rubocop-1.48.1/lib/rubocop/cop/commissioner.rb:87:in `investigate'
/Users/simon/.asdf/installs/ruby/3.2.1/lib/ruby/gems/3.2.0/gems/rubocop-1.48.1/lib/rubocop/cop/team.rb:156:in `investigate_partial'
/Users/simon/.asdf/installs/ruby/3.2.1/lib/ruby/gems/3.2.0/gems/rubocop-1.48.1/lib/rubocop/cop/team.rb:98:in `investigate'
/Users/simon/.asdf/installs/ruby/3.2.1/lib/ruby/gems/3.2.0/gems/rubocop-1.48.1/lib/rubocop/runner.rb:345:in `block in inspect_file'
/Users/simon/.asdf/installs/ruby/3.2.1/lib/ruby/gems/3.2.0/gems/rubocop-1.48.1/lib/rubocop/runner.rb:344:in `each'
/Users/simon/.asdf/installs/ruby/3.2.1/lib/ruby/gems/3.2.0/gems/rubocop-1.48.1/lib/rubocop/runner.rb:344:in `flat_map'
/Users/simon/.asdf/installs/ruby/3.2.1/lib/ruby/gems/3.2.0/gems/rubocop-1.48.1/lib/rubocop/runner.rb:344:in `inspect_file'
/Users/simon/.asdf/installs/ruby/3.2.1/lib/ruby/gems/3.2.0/gems/rubocop-1.48.1/lib/rubocop/runner.rb:287:in `block in do_inspection_loop'
/Users/simon/.asdf/installs/ruby/3.2.1/lib/ruby/gems/3.2.0/gems/rubocop-1.48.1/lib/rubocop/runner.rb:321:in `block in iterate_until_no_changes'
/Users/simon/.asdf/installs/ruby/3.2.1/lib/ruby/gems/3.2.0/gems/rubocop-1.48.1/lib/rubocop/runner.rb:314:in `loop'
/Users/simon/.asdf/installs/ruby/3.2.1/lib/ruby/gems/3.2.0/gems/rubocop-1.48.1/lib/rubocop/runner.rb:314:in `iterate_until_no_changes'
/Users/simon/.asdf/installs/ruby/3.2.1/lib/ruby/gems/3.2.0/gems/rubocop-1.48.1/lib/rubocop/runner.rb:283:in `do_inspection_loop'
/Users/simon/.asdf/installs/ruby/3.2.1/lib/ruby/gems/3.2.0/gems/rubocop-1.48.1/lib/rubocop/runner.rb:164:in `block in file_offenses'
/Users/simon/.asdf/installs/ruby/3.2.1/lib/ruby/gems/3.2.0/gems/rubocop-1.48.1/lib/rubocop/runner.rb:189:in `file_offense_cache'
/Users/simon/.asdf/installs/ruby/3.2.1/lib/ruby/gems/3.2.0/gems/rubocop-1.48.1/lib/rubocop/runner.rb:163:in `file_offenses'
/Users/simon/.asdf/installs/ruby/3.2.1/lib/ruby/gems/3.2.0/gems/rubocop-1.48.1/lib/rubocop/runner.rb:154:in `process_file'
/Users/simon/.asdf/installs/ruby/3.2.1/lib/ruby/gems/3.2.0/gems/rubocop-1.48.1/lib/rubocop/runner.rb:135:in `block in each_inspected_file'
/Users/simon/.asdf/installs/ruby/3.2.1/lib/ruby/gems/3.2.0/gems/rubocop-1.48.1/lib/rubocop/runner.rb:134:in `each'
/Users/simon/.asdf/installs/ruby/3.2.1/lib/ruby/gems/3.2.0/gems/rubocop-1.48.1/lib/rubocop/runner.rb:134:in `reduce'
/Users/simon/.asdf/installs/ruby/3.2.1/lib/ruby/gems/3.2.0/gems/rubocop-1.48.1/lib/rubocop/runner.rb:134:in `each_inspected_file'
/Users/simon/.asdf/installs/ruby/3.2.1/lib/ruby/gems/3.2.0/gems/rubocop-1.48.1/lib/rubocop/runner.rb:120:in `inspect_files'
/Users/simon/.asdf/installs/ruby/3.2.1/lib/ruby/gems/3.2.0/gems/rubocop-1.48.1/lib/rubocop/runner.rb:73:in `run'
/Users/simon/.asdf/installs/ruby/3.2.1/lib/ruby/gems/3.2.0/gems/rubocop-1.48.1/lib/rubocop/cli/command/execute_runner.rb:26:in `block in execute_runner'
/Users/simon/.asdf/installs/ruby/3.2.1/lib/ruby/gems/3.2.0/gems/rubocop-1.48.1/lib/rubocop/cli/command/execute_runner.rb:52:in `with_redirect'
/Users/simon/.asdf/installs/ruby/3.2.1/lib/ruby/gems/3.2.0/gems/rubocop-1.48.1/lib/rubocop/cli/command/execute_runner.rb:25:in `execute_runner'
/Users/simon/.asdf/installs/ruby/3.2.1/lib/ruby/gems/3.2.0/gems/rubocop-1.48.1/lib/rubocop/cli/command/execute_runner.rb:17:in `run'
/Users/simon/.asdf/installs/ruby/3.2.1/lib/ruby/gems/3.2.0/gems/rubocop-1.48.1/lib/rubocop/cli/command.rb:11:in `run'
/Users/simon/.asdf/installs/ruby/3.2.1/lib/ruby/gems/3.2.0/gems/rubocop-1.48.1/lib/rubocop/cli/environment.rb:18:in `run'
/Users/simon/.asdf/installs/ruby/3.2.1/lib/ruby/gems/3.2.0/gems/rubocop-1.48.1/lib/rubocop/cli.rb:118:in `run_command'
/Users/simon/.asdf/installs/ruby/3.2.1/lib/ruby/gems/3.2.0/gems/rubocop-1.48.1/lib/rubocop/cli.rb:125:in `execute_runners'
/Users/simon/.asdf/installs/ruby/3.2.1/lib/ruby/gems/3.2.0/gems/rubocop-1.48.1/lib/rubocop/cli.rb:51:in `block in run'
/Users/simon/.asdf/installs/ruby/3.2.1/lib/ruby/gems/3.2.0/gems/rubocop-1.48.1/lib/rubocop/cli.rb:77:in `profile_if_needed'
/Users/simon/.asdf/installs/ruby/3.2.1/lib/ruby/gems/3.2.0/gems/rubocop-1.48.1/lib/rubocop/cli.rb:43:in `run'
/Users/simon/.asdf/installs/ruby/3.2.1/lib/ruby/gems/3.2.0/gems/rubocop-1.48.1/exe/rubocop:19:in `block in <top (required)>'
/Users/simon/.asdf/installs/ruby/3.2.1/lib/ruby/3.2.0/benchmark.rb:311:in `realtime'
/Users/simon/.asdf/installs/ruby/3.2.1/lib/ruby/gems/3.2.0/gems/rubocop-1.48.1/exe/rubocop:19:in `<top (required)>'
/Users/simon/.asdf/installs/ruby/3.2.1/lib/ruby/gems/3.2.0/bin/rubocop:25:in `load'
/Users/simon/.asdf/installs/ruby/3.2.1/lib/ruby/gems/3.2.0/bin/rubocop:25:in `<top (required)>'
/Users/simon/.asdf/installs/ruby/3.2.1/lib/ruby/3.2.0/bundler/cli/exec.rb:58:in `load'
/Users/simon/.asdf/installs/ruby/3.2.1/lib/ruby/3.2.0/bundler/cli/exec.rb:58:in `kernel_load'
/Users/simon/.asdf/installs/ruby/3.2.1/lib/ruby/3.2.0/bundler/cli/exec.rb:23:in `run'
/Users/simon/.asdf/installs/ruby/3.2.1/lib/ruby/3.2.0/bundler/cli.rb:491:in `exec'
/Users/simon/.asdf/installs/ruby/3.2.1/lib/ruby/3.2.0/bundler/vendor/thor/lib/thor/command.rb:27:in `run'
/Users/simon/.asdf/installs/ruby/3.2.1/lib/ruby/3.2.0/bundler/vendor/thor/lib/thor/invocation.rb:127:in `invoke_command'
/Users/simon/.asdf/installs/ruby/3.2.1/lib/ruby/3.2.0/bundler/vendor/thor/lib/thor.rb:392:in `dispatch'
/Users/simon/.asdf/installs/ruby/3.2.1/lib/ruby/3.2.0/bundler/cli.rb:34:in `dispatch'
/Users/simon/.asdf/installs/ruby/3.2.1/lib/ruby/3.2.0/bundler/vendor/thor/lib/thor/base.rb:485:in `start'
/Users/simon/.asdf/installs/ruby/3.2.1/lib/ruby/3.2.0/bundler/cli.rb:28:in `start'
/Users/simon/.asdf/installs/ruby/3.2.1/lib/ruby/gems/3.2.0/gems/bundler-2.4.6/libexec/bundle:45:in `block in <top (required)>'
/Users/simon/.asdf/installs/ruby/3.2.1/lib/ruby/3.2.0/bundler/friendly_errors.rb:117:in `with_friendly_errors'
/Users/simon/.asdf/installs/ruby/3.2.1/lib/ruby/gems/3.2.0/gems/bundler-2.4.6/libexec/bundle:33:in `<top (required)>'
/Users/simon/.asdf/installs/ruby/3.2.1/bin/bundle:25:in `load'
/Users/simon/.asdf/installs/ruby/3.2.1/bin/bundle:25:in `<main>'
.

1 file inspected, no offenses detected

1 error occurred:
An error occurred while Layout/HashAlignment cop was inspecting /Users/simon/dev/work/dodo/fakturabank/repo/spec/views/payments/new_spec.rb:74:6.
Errors are usually caused by RuboCop bugs.
Please, report your problems to RuboCop's issue tracker.
https://github.com/rubocop/rubocop/issues

Mention the following information in the issue report:
1.48.1 (using Parser <IP_ADDRESS>, rubocop-ast 1.27.0, running on ruby 3.2.1) [arm64-darwin22]
Finished in 0.3613330000080168 seconds

Steps to reproduce the problem
This is extremely important! Providing us with a reliable way to reproduce
a problem will expedite its solution.
RuboCop version
Include the output of rubocop -V or bundle exec rubocop -V if using Bundler.
If you see extension cop versions (e.g. rubocop-performance, rubocop-rspec, and others)
output by rubocop -V, include them as well. Here's an example:
$ be rubocop -V
1.48.1 (using Parser <IP_ADDRESS>, rubocop-ast 1.27.0, running on ruby 3.2.1) [arm64-darwin22]
  - rubocop-capybara 2.17.1
  - rubocop-performance 1.16.0
  - rubocop-rails 2.18.0
  - rubocop-rspec 2.19.0

I cloned the this project to write a test for you. but I'm not sure I have added it to the correct place. And my code works fine when I remove ** from the hash arg but my test still rails. I think this has to do ruby that this is a new ruby feature but I don't know.
diff --git a/spec/rubocop/cop/layout/hash_alignment_spec.rb b/spec/rubocop/cop/layout/hash_alignment_spec.rb
index c827b0319..54174853e 100644
--- a/spec/rubocop/cop/layout/hash_alignment_spec.rb
+++ b/spec/rubocop/cop/layout/hash_alignment_spec.rb
@@ -795,6 +795,19 @@ RSpec.describe RuboCop::Cop::Layout::HashAlignment, :config do
       RUBY
     end

+    it 'accepts anonymous keyword arguments as element in hash' do
+      expect_no_offenses(<<~RUBY)
+        def hey(...) = nil
+        def insert(*, **)
+          hey(
+            :invoice, *,
+            a: 1,
+            **
+          )
+        end
+      RUBY
+    end
+
     it 'accepts a symbol only hash followed by a keyword splat' do
       expect_no_offenses(<<~RUBY)
         hash = {

For next time: Is it good too include a failing spec like this in the issue?

My only hesitation is: do we want a different class, or could we not use Kwsplat?


ReadonlyArray.takeRight is missing in docs

📖 Documentation
https://gcanti.github.io/fp-ts/modules/ReadonlyArray.ts.html#takeleft
RA.takeLeft and RA.takeLeftWhile are documented, unfortunately RA.takeRight is not.

It is documented, it just has a different category.
I've created a PR: https://github.com/gcanti/fp-ts/pull/1575


Add an option to create an option inside the select

Would be nice to have a bit more details on the issue, but I agree with your point.
I'll edit your comment with the specs.


ARROW-10441: [Java] Prevent closure of shared channels for FlightClient

Add a proxy for ManagedChannel to prevent closure of shared
channels when specified for FlightClient in FlightGrpcUtils.

@lidavidm here's a PR for the shared channel issue: https://issues.apache.org/jira/browse/ARROW-10441

@lidavidm I believe the JNI issue is not related and is a common problem - how can we get this merged?

No problem, I was just waiting for other builds to pass. Thanks!


Cannot update email marketing consent state if opt-in level doesn't change

Issue summary
Before opening this issue, I have:

[x] Upgraded to the latest version of the package

shopify_api version: 2024-01
Ruby version: 3.2.3
Operating system: Ubuntu 22.04 LTS

[ ] Set log_level: :debug in my configuration, if applicable
[x] Found a reliable way to reproduce the problem that indicates it's a problem with the package
[x] Looked for similar issues in this repository
[x] Checked that this isn't an issue with a Shopify API

If it is, please create a post in the Shopify community forums or report it to Shopify Partner Support

When updating a customer's email marketing consent state, the Shopify API seems to require both the state and opt_in_level. However, if the opt_in_level does not change, the gem does not send up the opt_in_level part of the hash, which results in a 422.
Aside: The process of updating a customer's email marketing consent is not well documented. The official REST docs have an example titled "update a customer's marketing opt-in state" but it uses the old, deprecated parameters.
Expected behavior
The gem should send up all required parameters, regardless of whether or not they change.
Actual behavior
The gem only sends up fields that change, this makes it impossible to update a customer's email marketing consent state when the opt-in level doesn't change.
Steps to reproduce the problem

Fetch a customer from Shopify
Create a new hash for the email_marketing_consent field that contains all the same attributes, but a different state (e.g. use "subscribed" if the customer was not subscribed)
Try to save the customer

Alternatively, try adding these tests to the test/rest/2024_01/customer_test.rb file.
The first test is a "control" to ensure the test works as expected when the opt-in level changes. This test should pass.
  sig do
    void
  end
  def test_x_control
    session = ShopifyAPI::Auth::Session.new(
      shop: "test-shop.myshopify.io",
      access_token: "this_is_a_test_token"
    )

    # Simulate fetching an existing customer via the API:
    customer = ShopifyAPI::Customer.create_instance(
      session: session,
      data: {
        "id" => 207119551,
        "email_marketing_consent" => {
          "state" => "not_subscribed",
          "opt_in_level" => "confirmed_opt_in",
          "consent_updated_at" => "2023-01-01T00:00:00.000Z"
        }
      }
    )

    # Stub update with full `email_marketing_consent` hash included:
    stub_request(:put, "https://test-shop.myshopify.io/admin/api/2024-01/customers/207119551.json")
      .with(
        # This stub matches because `opt_in_level` changes.
        body: { "customer" => hash_including({"email_marketing_consent" => {"state" => "subscribed", "opt_in_level" => "single_opt_in", "consent_updated_at" => "2024-01-01T00:00:00.000Z"}}) }
      )
      .to_return(status: 200, body: JSON.generate({"customer" => {"email" =><EMAIL_ADDRESS>"first_name" => "Bob", "last_name" => "Norman", "id" => 207119551, "accepts_marketing" => false, "created_at" => "2024-01-02T09:24:29-05:00", "updated_at" => "2024-01-02T09:24:29-05:00", "orders_count" => 1, "state" => "disabled", "total_spent" => "199.65", "last_order_id" => 450789469, "note" => nil, "verified_email" => true, "multipass_identifier" => nil, "tax_exempt" => false, "tags" => "L\u00E9on, No\u00EBl", "last_order_name" => "#1001", "currency" => "USD", "phone" => "+16136120707", "addresses" => [{"id" => 207119551, "customer_id" => 207119551, "first_name" => nil, "last_name" => nil, "company" => nil, "address1" => "Chestnut Street 92", "address2" => "", "city" => "Louisville", "province" => "Kentucky", "country" => "United States", "zip" => "40202", "phone" => "555-625-1199", "name" => "", "province_code" => "KY", "country_code" => "US", "country_name" => "United States", "default" => true}], "accepts_marketing_updated_at" => "2005-06-12T11:57:11-04:00", "marketing_opt_in_level" => nil, "tax_exemptions" => [], "email_marketing_consent" => {"state" => "not_subscribed", "opt_in_level" => nil, "consent_updated_at" => "2004-06-13T11:57:11-04:00"}, "sms_marketing_consent" => {"state" => "not_subscribed", "opt_in_level" => "single_opt_in", "consent_updated_at" => "2024-01-02T09:24:29-05:00", "consent_collected_from" => "OTHER"}, "admin_graphql_api_id" => "gid://shopify/Customer/207119551", "default_address" => {"id" => 207119551, "customer_id" => 207119551, "first_name" => nil, "last_name" => nil, "company" => nil, "address1" => "Chestnut Street 92", "address2" => "", "city" => "Louisville", "province" => "Kentucky", "country" => "United States", "zip" => "40202", "phone" => "555-625-1199", "name" => "", "province_code" => "KY", "country_code" => "US", "country_name" => "United States", "default" => true}}}), headers: {})

    customer.email_marketing_consent = {
      "state" => "subscribed",
      "opt_in_level" => "single_opt_in",
      "consent_updated_at" => "2024-01-01T00:00:00.000Z"
    }

    # Trigger put request which will match the stubbed request.
    customer.save

    assert_requested(:put, "https://test-shop.myshopify.io/admin/api/2024-01/customers/207119551.json")
  end

The second test is the same as the first, the only difference is that the opt-in level stays the same. This test currently fails (but should pass when the bug gets fixed).
  sig do
    void
  end
  def test_x_broken
    session = ShopifyAPI::Auth::Session.new(
      shop: "test-shop.myshopify.io",
      access_token: "this_is_a_test_token"
    )

    # Simulate fetching an existing customer via the API:
    customer = ShopifyAPI::Customer.create_instance(
      session: session,
      data: {
        "id" => 207119551,
        "email_marketing_consent" => {
          "state" => "not_subscribed",
          "opt_in_level" => "single_opt_in",
          "consent_updated_at" => "2023-01-01T00:00:00.000Z"
        }
      }
    )

    # Stub update with full `email_marketing_consent` hash included:
    stub_request(:put, "https://test-shop.myshopify.io/admin/api/2024-01/customers/207119551.json")
      .with(
        # This stub isn't going to match because the `opt_in_level` doesn't change and therefore isn't sent up.
        body: { "customer" => hash_including({"email_marketing_consent" => {"state" => "subscribed", "opt_in_level" => "single_opt_in", "consent_updated_at" => "2024-01-01T00:00:00.000Z"}}) }
      )
      .to_return(status: 200, body: JSON.generate({"customer" => {"email" =><EMAIL_ADDRESS>"first_name" => "Bob", "last_name" => "Norman", "id" => 207119551, "accepts_marketing" => false, "created_at" => "2024-01-02T09:24:29-05:00", "updated_at" => "2024-01-02T09:24:29-05:00", "orders_count" => 1, "state" => "disabled", "total_spent" => "199.65", "last_order_id" => 450789469, "note" => nil, "verified_email" => true, "multipass_identifier" => nil, "tax_exempt" => false, "tags" => "L\u00E9on, No\u00EBl", "last_order_name" => "#1001", "currency" => "USD", "phone" => "+16136120707", "addresses" => [{"id" => 207119551, "customer_id" => 207119551, "first_name" => nil, "last_name" => nil, "company" => nil, "address1" => "Chestnut Street 92", "address2" => "", "city" => "Louisville", "province" => "Kentucky", "country" => "United States", "zip" => "40202", "phone" => "555-625-1199", "name" => "", "province_code" => "KY", "country_code" => "US", "country_name" => "United States", "default" => true}], "accepts_marketing_updated_at" => "2005-06-12T11:57:11-04:00", "marketing_opt_in_level" => nil, "tax_exemptions" => [], "email_marketing_consent" => {"state" => "not_subscribed", "opt_in_level" => nil, "consent_updated_at" => "2004-06-13T11:57:11-04:00"}, "sms_marketing_consent" => {"state" => "not_subscribed", "opt_in_level" => "single_opt_in", "consent_updated_at" => "2024-01-02T09:24:29-05:00", "consent_collected_from" => "OTHER"}, "admin_graphql_api_id" => "gid://shopify/Customer/207119551", "default_address" => {"id" => 207119551, "customer_id" => 207119551, "first_name" => nil, "last_name" => nil, "company" => nil, "address1" => "Chestnut Street 92", "address2" => "", "city" => "Louisville", "province" => "Kentucky", "country" => "United States", "zip" => "40202", "phone" => "555-625-1199", "name" => "", "province_code" => "KY", "country_code" => "US", "country_name" => "United States", "default" => true}}}), headers: {})

    customer.email_marketing_consent = {
      "state" => "subscribed",
      "opt_in_level" => "single_opt_in",
      "consent_updated_at" => "2024-01-01T00:00:00.000Z"
    }

    # Trigger put request which won't match the stubbed request.
    customer.save

    assert_requested(:put, "https://test-shop.myshopify.io/admin/api/2024-01/customers/207119551.json")
  end

Debug logs
// Paste any relevant logs here

Hi @ClaytonPassmore, thank you for opening an issue with this level of detail! I'm going to add it to our internal workflow.

Awesome, thank you @matteodepalo 🙏


Handle missing image

If ContainerDo.toml refers to an image tag that is not present in the local Docker demon, we expect it to pull the image or print a helpful error. Instead, the actual behaviour is:
exit status 1

With debug information:
2021-03-16T15:22:22.861+0100	DEBUG	container-do/runner_docker.go:17	Will run command: `docker inspect --format={{.Config.WorkingDir}} some-image`
2021-03-16T15:22:22.923+0100	DEBUG	container-do/runner_docker.go:27	Docker command quit with status 1
2021-03-16T15:22:22.923+0100	DEBUG	container-do/runner_docker.go:33	Command output: 'Error: No such object: some-image'

Analysis: We used to run docker create first; since #12 (or one of the follow-ups), though, we try to determine the working directory before that using docker inspect.
Plan: Silent pulling was always awkward because of the unannounced delay, and bad failure behaviour in case the registry needs a login. Check if the tag exists; if not, print a clear error asking the user to docker pull.

Fixed in 1.2.4


chore(main): release iso-signatures 0.1.6

:robot: I have created a release beep boop
0.1.6 (2023-06-30)
Bug Fixes

add more types definitions to npm files and export asn1 and spki (80860de)

This PR was generated with Release Please. See documentation.

:robot: Release is at https://github.com/hugomrdias/iso-repo/releases/tag/iso-signatures-v0.1.6 :sunflower:


new release of node-gyp

@rvagg @TooTallNate Would it be possible make a v3.0.4 release based on this https://github.com/nodejs/node-gyp/compare/f5d86eb...9049241
We would like to have these changes pulled into npm and ultimately node
For reference the original pull request https://github.com/nodejs/node-gyp/pull/781

done, chose a cautionary semver-minor for it, so it's v3.1.0.


Parquet writer classes don't close underlying output stream in case of errors.

org.apache.parquet.io.OutputFile interface does not implement Closeable.
In my opinion it implies that created streams are fully managed by parquet-mr classes.
Unfortunately opened stream will not be closed in case of IO or other failure.
There are two places I can find for this problem:

During writer creation (org.apache.parquet.hadoop.ParquetWriter.Builder#build()) - created stream should be closed if writer creation fails.
During writer close(org.apache.parquet.hadoop.ParquetWriter#close) - underlying stream should be closed regardless of any faced failures.
Although I didn't examine ParquetReaded that much.

Reporter: Andrei Lopukhov
Original Issue Attachments:

TestExample.java

Note: This issue was originally created as PARQUET-2216. Please see the migration documentation for further details.

Andrei Lopukhov:
It would be great if committers/contributors could confirm this.

Steve Loughran / @steveloughran:

OutputFile may not implement Closeable, but the PositionOutputStream returned by the {{create())) method does.

the writer close chain seems to go all the way through too.
looking at the code, one place for improvement would be for ParquetFileWriter.end(Map<String, String> extraMetaData) to close  its output stream in  a finally() clause, so even if the write of the footer failed, the local fs client would do all it can to cleanup, release connections etc.


Gradle Kotlin-DSL has double quotes and parenthesis

Can you add an option --format=[kotlin|groovy]  to generate the dependency information compatible with build.gradle for groovy and build.gradle.kts for kotlin?
Ideally calling with no format argument should use the previous value
--format=kotlin would be like this:
dependencies {
  implementation("com.squareup.picaso:picaso:2.5.2")
}

it doesn't work without () anymore?

Correct,

in kotlin build.gradle.kts, it doesn't work without () (implementation is a normal extension method)
in kotlin build.gradle.kts, it doesn't work with simple quotes (like in java)
in groovy build.gradle, implementation("com.squareup.picaso:picaso:2.5.2")` with parenthesis and double quotes is actually an accepted syntax.

So actually, instead of having an option --format=kotlin|groovy, we could just change the dependency format to implementation("com.squareup.picaso:picaso:2.5.2") and be compatible with both!

@cesarferreira would you be interested by a pull-request where I change the output so that it works both in a build.gradle and a build.gradle.kts file?
dependencies {
-  implementation 'com.squareup.picaso:picaso:2.5.2'
+  implementation("com.squareup.picaso:picaso:2.5.2")
}

Yes please @jmfayard

@cesarferreira done! The first line of ruby I ever wrote, hopefully not wrong :)

It works, thanks for the PR

btw @jmfayard love the idea on your lib https://github.com/jmfayard/gradle-kotlin-dsl-libs


Fixed event pages issues

Signed-off-by: Suneel Nadipalli<EMAIL_ADDRESS>Fixes #

Fixed text visibility issues in event pages

#103 #102 #101 #100 #99 #98 #97 #96 #95 #94 #93 #92 #90 #104


Interlock lb port is 8080

File: ee/ucp/interlock/usage/ssl.md, CC @johndmulhausen
See https://beta.docs.docker.com/ee/ucp/interlock/usage/ssl/
Could you explain why in the configuration of the service
docker service create \
    --name demo \
    --network demo \
    --label com.docker.lb.hosts=demo.local \
    --label com.docker.lb.port=8080 \
    --label com.docker.lb.ssl_cert=demo.local.cert \
    --label com.docker.lb.ssl_key=demo.local.key \
    ehazlett/docker-demo

Why is the label com.docker.lb.port set to 8080 ?

The ehazlett/docker-demo app listens on port 8080 for traffic, so what this snippet does is:

Deploy the service, but there's no need to use --pubish because we don't want to expose that port to the outside world.
Attach this service to the demo network. Interlock will reconfigure the Proxy service to also be attached to this network. This way the proxy and the service can communicate.
The com.docker.lb.hosts tells Interlock to route traffic for the host demo.local to this service.
The com.docker.lb.port tells Interlock to use port 8080 when routing to the service, since we know the service is listening on that port.
The other labels tell the TLS certificate and key to use for the Interlock proxy service.

Now you might wonder, how do we know that the ehazlett/docker-demo app listens on port 8080?
The docs don't say it, but one way you can figure it out is by inspecting the image:
docker image inspect --format '{{ .ContainerConfig.ExposedPorts }}' ehazlett/docker-demo

@NicoTexas this functionality/docs are part of the UCP 3.0 beta, so the best place to get help and provide feedback is at https://forums.docker.com/c/docker-data-center/eebeta
I'm also working on improving these docs right now, but that is being tracked on an upstream repo. For that reason I'll be closing this issue.