PrimeIntellect/SWE-rebench-V2 huggingface dataset:
Repository: allegro/marathon-consul (go)

Issue:
Handle Mesos healthchecks
Mesos 1.1 introduces HTTP/S and TCP healthchecks. Marathon will support this healthchecks from 1.4. We need to support them too. 

Pull request:
Fixes #151 | Handle Mesos healthchecks

Patch:
diff --git a/consul/consul.go b/consul/consul.go
index b5688ae..6924267 100644
--- a/consul/consul.go
+++ b/consul/consul.go
@@ -323,9 +323,13 @@ func (c *Consul) marathonToConsulChecks(task *apps.Task, healthChecks []apps.Hea
 		}
 
 		switch check.Protocol {
-		case "HTTP", "HTTPS":
+		case "HTTP", "HTTPS", "MESOS_HTTP", "MESOS_HTTPS":
 			if parsedURL, err := url.ParseRequestURI(check.Path); err == nil {
-				parsedURL.Scheme = strings.ToLower(check.Protocol)
+				if check.Protocol == "HTTP" || check.Protocol == "MESOS_HTTP" {
+					parsedURL.Scheme = "http"
+				} else {
+					parsedURL.Scheme = "https"
+				}
 				parsedURL.Host = fmt.Sprintf("%s:%d", serviceAddress, port)
 				consulCheck.HTTP = parsedURL.String()
 				checks = append(checks, &consulCheck)
@@ -335,7 +339,7 @@ func (c *Consul) marathonToConsulChecks(task *apps.Task, healthChecks []apps.Hea
 					WithField("Address", serviceAddress).
 					Warn(fmt.Sprintf("Could not parse provided path: %s", check.Path))
 			}
-		case "TCP":
+		case "TCP", "MESOS_TCP":
 			consulCheck.TCP = fmt.Sprintf("%s:%d", serviceAddress, port)
 			checks = append(checks, &consulCheck)
 		case "COMMAND":


Test patch:
diff --git a/consul/consul_test.go b/consul/consul_test.go
index 0c17f55..5feb247 100644
--- a/consul/consul_test.go
+++ b/consul/consul_test.go
@@ -829,7 +829,7 @@ func TestMarathonTaskToConsulServiceMapping_IgnoredHealthcheckTypes(t *testing.T
 		HealthChecks: []apps.HealthCheck{
 			{
 				Path:                   "/api/health?with=query",
-				Protocol:               "HTTP",
+				Protocol:               "MESOS_HTTP",
 				PortIndex:              0,
 				IntervalSeconds:        60,
 				TimeoutSeconds:         20,
Repository: zitadel/oidc (go)

Issue:
[bug]: missing client_id claim in access token JWT
### Discussed in https://github.com/zitadel/oidc/discussions/646

<div type='discussions-op-text'>

<sup>Originally posted by **duizabojul** September  4, 2024</sup>
id_token got these claims but not access_token? Is there a reason for this? [RFC tells client_id is required in access token](https://datatracker.ietf.org/doc/html/rfc9068#name-data-structure).</div>

Pull request:
fix(oidc): set client ID to access token JWT
RFC 9068: JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens, section 2.2. https://datatracker.ietf.org/doc/html/rfc9068#name-data-structure defines `client_id` as a required claim. This fix sets the claim in the `NewAccessTokenClaims` function.

Closes #649

### Definition of Ready

- [x] I am happy with the code
- [x] Short description of the feature/issue is added in the pr description
- [x] PR is linked to the corresponding user story
- [x] Acceptance criteria are met
- [x] All open todos and follow ups are defined in a new ticket and justified
- [x] Deviations from the acceptance criteria and design are agreed with the PO and documented.
- [x] No debug or dead code
- [x] My code has no repetitions
- [x] Critical parts are tested automatically
- [x] Where possible E2E tests are implemented
- [x] Documentation/examples are up-to-date
- [x] All non-functional requirements are met
- [x] Functionality of the acceptance criteria is checked manually on the dev system.



Patch:
diff --git a/pkg/oidc/token.go b/pkg/oidc/token.go
index 5b18dac..a829df4 100644
--- a/pkg/oidc/token.go
+++ b/pkg/oidc/token.go
@@ -117,6 +117,7 @@ func NewAccessTokenClaims(issuer, subject string, audience []string, expiration
 			Expiration: FromTime(expiration),
 			IssuedAt:   FromTime(now),
 			NotBefore:  FromTime(now),
+			ClientID:   clientID,
 			JWTID:      jwtid,
 		},
 	}


Test patch:
diff --git a/pkg/oidc/token_test.go b/pkg/oidc/token_test.go
index ccc3467..7847cb5 100644
--- a/pkg/oidc/token_test.go
+++ b/pkg/oidc/token_test.go
@@ -145,6 +145,7 @@ func TestNewAccessTokenClaims(t *testing.T) {
 			Subject:    "hello@me.com",
 			Audience:   Audience{"foo"},
 			Expiration: 12345,
+			ClientID:   "foo",
 			JWTID:      "900",
 		},
 	}
Repository: adobe/elixir-styler (elixir)

Issue:
Produces compiler errors for Ecto queries using "in" macro
## Elixir / OTP Version
```
❯ cat .tool-versions 
elixir 1.14.1-otp-25
erlang 25.1.1
```

## Current Behaviour

For several of my work projects, we do `require Ecto.Query` (instead of `import Ecto.Query, only: ...`) and then call `Ecto.Query.from(...)`. Inside of [the `from` macro](https://github.com/elixir-ecto/ecto/blob/v3.10.1/lib/ecto/query.ex#L939), an unqualified `in` is valid. However, `elixir-styler` makes the following change:

<img width="1137" alt="Screenshot 2023-05-04 at 8 22 32 AM" src="https://user-images.githubusercontent.com/3588798/236254197-8f819b66-b088-44fb-a180-d8ed3b636e2b.png">

<img width="1165" alt="Screenshot 2023-05-04 at 8 10 36 AM" src="https://user-images.githubusercontent.com/3588798/236251322-8bae6844-4450-4e90-959d-d63b304d2bda.png">

Which causes a compilation error:
```
syntax error before: in. "in" is a reserved word in Elixir and therefore its usage is limited. For instance, it can't be used as a variable or be defined nor invoked as a regular function
```

A fix in this case is to change `in` to `Ecto.Query.in`.

## Expected Behaviour

I'm not sure how to avoid this, unless `elixir-styler` is able to detect which functions are macros and skip them or automatically fully qualify them?

Pull request:
Bug: include Ecto.Query.from as a valid pipe start
Closes #24

This error makes me think that it's likely that other macro DSLs will work poorly with the pipes op, but we'll see what crops up

Patch:
diff --git a/lib/style/pipes.ex b/lib/style/pipes.ex
index 6b582d2..52d3765 100644
--- a/lib/style/pipes.ex
+++ b/lib/style/pipes.ex
@@ -179,6 +179,8 @@ defmodule Styler.Style.Pipes do
   defp valid_pipe_start?({:unquote, _, _}), do: true
   # ecto
   defp valid_pipe_start?({:from, _, _}), do: true
+  defp valid_pipe_start?({{:., _, [{_, _, [:Query]}, :from]}, _, _}), do: true
+  defp valid_pipe_start?({{:., _, [{_, _, [:Ecto, :Query]}, :from]}, _, _}), do: true
   # most of these values were lifted directly from credo's pipe_chain_start.ex
   @value_constructors ~w(% %{} .. <<>> @ {} & fn)a
   @simple_operators ~w(++ -- && ||)a


Test patch:
diff --git a/test/style/pipes_test.exs b/test/style/pipes_test.exs
index c0bb6e6..c669942 100644
--- a/test/style/pipes_test.exs
+++ b/test/style/pipes_test.exs
@@ -473,11 +473,13 @@ defmodule Styler.Style.PipesTest do
     end
 
     test "allows ecto's from" do
-      assert_style("""
-      from(foo in Bar, where: foo.bool)
-      |> some_query_helper()
-      |> Repo.all()
-      """)
+      for from <- ~w(from Query.from Ecto.Query.from) do
+        assert_style("""
+        #{from}(foo in Bar, where: foo.bool)
+        |> some_query_helper()
+        |> Repo.all()
+        """)
+      end
     end
 
     test "extracts >0 arity functions" do