sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: java-design-patterns
Issue: Microservice pattern: 3rd party registration
Labels: info: help wanted,epic: pattern,type: feature,status: stale

### Description:
The 3rd Party Registration design pattern is a fundamental microservices architecture pattern. This pattern involves registering third-party services with our system, allowing them to be easily discoverable and usable by other services within the ecosystem. By implementing this pattern, we ensure that our system can dynamically integrate and manage external services, enhancing modularity and scalability.

Key Elements of the 3rd Party Registration Design Pattern:
- **Service Registry**: A central registry where third-party services are registered and managed.
- **Service Discovery**: Mechanism for other services to discover and connect to registered third-party services.
- **Registration Protocol**: Standardized protocol for third-party services to register with the service registry.
- **Health Check**: Regular monitoring of the registered services to ensure they are operational.
- **Security**: Ensuring secure communication and authentication between services and the registry.

### References:
- [Microservices Patterns](https://microservices.io/patterns/3rd-party-registration.html)
- [Martin Fowler - Microservices](https://martinfowler.com/articles/microservices.html)
- [Java Design Patterns Wiki](https://github.com/iluwatar/java-design-patterns/wiki)
- [Service Registration and Discovery - Spring Cloud](https://spring.io/guides/gs/service-registration-and-discovery/)

### Acceptance Criteria:
1. A central service registry is implemented, allowing third-party services to register themselves.
2. Implement service discovery to enable other services to find and connect to registered third-party services.
3. Develop a standardized registration protocol that third-party services can use to register with the service registry.
4. Implement health checks to monitor the status of registered services and handle any failures gracefully.
5. Ensure secure communication and authentication mechanisms are in place between services and the registry.
Repository: java-design-patterns
Issue: Microservice pattern: Access token
Labels: info: help wanted,epic: pattern,type: feature

**Description:**
The Access Token design pattern is crucial for managing secure communication between microservices. This pattern involves the use of tokens, typically JWT (JSON Web Tokens), to verify the identity and permissions of a user or service making a request to another service. Implementing this pattern enhances security, scalability, and maintainability of microservices by decoupling authentication logic from individual services.

**Main Elements:**
1. **Token Issuance:** A trusted authority (Authorization Server) issues tokens after authenticating a user or service.
2. **Token Validation:** Microservices validate the tokens to ensure the request is authenticated and authorized.
3. **Token Scope and Permissions:** Tokens carry claims about the user's identity and permissions, defining what resources and operations the user is allowed to access.
4. **Token Expiry and Refresh:** Tokens have a limited lifespan, and mechanisms must be in place to refresh tokens when they expire.
5. **Security Measures:** Implementing security measures to protect tokens in transit and at rest, including the use of HTTPS and secure storage.

**References:**
- [Microservices Security Patterns](https://microservices.io/patterns/security/access-token.html)
- [OAuth 2.0 and OpenID Connect](https://oauth.net/2/)
- [JSON Web Tokens (JWT)](https://jwt.io/introduction/)
- [Spring Security OAuth2](https://spring.io/projects/spring-security-oauth)

**Acceptance Criteria:**
1. Implement a token issuance mechanism using a trusted Authorization Server.
2. Ensure microservices can validate the tokens received in incoming requests.
3. Define token scopes and permissions to control access to different resources and operations.
4. Implement token expiry and refresh mechanisms to manage token lifecycle.
5. Ensure all communication involving tokens is secure, using HTTPS and appropriate storage solutions for tokens.

Please ensure adherence to the [project contribution guidelines](https://github.com/iluwatar/java-design-patterns/wiki) while working on this issue.
Repository: java-design-patterns
Issue: Microservice pattern: Application metrics
Labels: info: help wanted,epic: pattern,type: feature,status: stale

**Description:**

Implement the Application Metrics design pattern for a microservices architecture. This pattern involves collecting, aggregating, and analyzing metrics from various microservices to monitor their performance and health. Key elements of this pattern include:

1. **Metric Collection**: Gather data points from each microservice, such as response times, error rates, and request counts.
2. **Aggregation and Storage**: Consolidate metrics in a centralized repository for easy access and analysis.
3. **Monitoring and Visualization**: Use tools to monitor real-time metrics and visualize historical data to identify trends and issues.
4. **Alerting and Notifications**: Set up alerts to notify relevant stakeholders when metrics indicate potential problems.
5. **Automated Response**: Implement automated actions to remediate issues based on specific metric thresholds.

**References:**
- [Java Design Patterns Wiki](https://github.com/iluwatar/java-design-patterns/wiki)
- [Microservices Architecture Patterns](https://martinfowler.com/microservices/)
- [Application Metrics with Prometheus](https://prometheus.io/docs/introduction/overview/)
- [Spring Boot Actuator](https://docs.spring.io/spring-boot/docs/current/reference/html/actuator.html)
- [ELK Stack for Metrics](https://www.elastic.co/what-is/elk-stack)
- [Application Metrics pattern](https://microservices.io/patterns/observability/application-metrics.html)

**Acceptance Criteria:**
1. Implement metric collection for key performance indicators (KPIs) such as response times, error rates, and request counts in each microservice.
2. Develop a centralized aggregation and storage mechanism for collected metrics, utilizing tools such as Prometheus or the ELK stack.
3. Create a monitoring dashboard that visualizes the real-time and historical performance of the microservices.
4. Set up alerting mechanisms to notify stakeholders of potential issues based on predefined metric thresholds.
5. Implement automated responses to specific metric thresholds to ensure high availability and reliability of the microservices.

Please follow the project's contribution guidelines as outlined in the [Java Design Patterns Wiki](https://github.com/iluwatar/java-design-patterns/wiki) when submitting your implementation.
Repository: java-design-patterns
Issue: Microservice pattern: Audit logging
Labels: info: help wanted,epic: pattern,type: feature

**Description:**

The Audit Logging design pattern is crucial for microservices architectures, providing a means to record significant events and changes within the system. This pattern helps in maintaining a comprehensive trail of activities, which is vital for debugging, security audits, and compliance purposes. 

Key elements of the Audit Logging design pattern include:
1. **Centralized Logging Service:** A dedicated service responsible for receiving and storing logs from various microservices.
2. **Log Formatter:** Standardized format for logs to ensure consistency and readability.
3. **Security and Compliance:** Ensure logs are stored securely and comply with regulatory requirements.
4. **Log Filtering and Aggregation:** Ability to filter and aggregate logs to extract meaningful insights.
5. **Scalability:** The logging service should handle a high volume of logs efficiently.
6. **Performance:** Logging should not adversely impact the performance of microservices.

**References:**
- [Project Contribution Guidelines](https://github.com/iluwatar/java-design-patterns/wiki)
- [Microservices Patterns](https://microservices.io/patterns/observability/audit-logging.html)
- [Audit Logging in Microservices](https://docs.microsoft.com/en-us/azure/architecture/microservices/logging-monitoring)

**Acceptance Criteria:**
1. Implement a centralized logging service that can receive logs from various microservices.
2. Ensure logs are formatted consistently using a standard log formatter.
3. Implement security measures to protect log data and ensure compliance with relevant regulations.
4. Develop mechanisms for log filtering and aggregation to facilitate meaningful analysis.
5. Validate that the logging service can scale and handle high volumes of log data efficiently.
6. Ensure the logging mechanism has minimal impact on the performance of the microservices.
Repository: java-design-patterns
Issue: Microservice pattern: Exception tracking
Labels: info: help wanted,epic: pattern,type: feature,status: stale

### Description
The Exception Tracking design pattern in microservices architecture involves the centralized handling and logging of exceptions that occur across different services. This pattern is essential for monitoring, debugging, and maintaining the health of a distributed system by providing a unified view of errors and their origins.

**Main Elements of the Pattern:**
1. **Centralized Exception Logger**: A dedicated service or tool that aggregates and stores exception data from various microservices.
2. **Exception Handling Middleware**: Middleware components in each microservice that catch and forward exceptions to the centralized logger.
3. **Correlation ID**: Unique identifiers that help trace the flow of requests and corresponding exceptions across multiple services.
4. **Alerting and Monitoring**: Integration with monitoring tools to alert the development and operations teams about critical issues in real-time.
5. **Dashboard**: A user interface that provides insights and analytics on exceptions, including frequency, severity, and potential impact.

### References
1. [Project Contribution Guidelines](https://github.com/iluwatar/java-design-patterns/wiki)
2. [Microservices Architecture](https://martinfowler.com/microservices/)
3. [Exception Handling Patterns](https://docs.microsoft.com/en-us/azure/architecture/patterns/exception-tracking)
4. [Centralized Logging in Microservices](https://www.redhat.com/en/topics/microservices/what-is-microservices-logging)

### Acceptance Criteria
- Implement a centralized exception logger service that aggregates exception data from all microservices.
- Develop middleware components for each microservice to catch and forward exceptions to the centralized logger.
- Implement correlation IDs to trace the flow of requests and exceptions across microservices.
- Integrate the centralized logger with monitoring and alerting tools to notify the team of critical issues.
- Create a dashboard to visualize and analyze exception data, providing insights on frequency, severity, and impact.
Repository: java-design-patterns
Issue: Microservice pattern: Log deployments and changes
Labels: info: help wanted,epic: pattern,type: feature

**Description:**
The objective is to implement the Microservices - Log Deployments and Changes design pattern in our project. This pattern ensures that all deployments and changes to the microservices architecture are logged effectively. This enhances traceability, debugging, and auditing processes, making it easier to maintain the health and stability of the system.

**Main elements of the pattern:**

1. **Centralized Logging System**: Implement a centralized logging system to capture logs from all microservices. This helps in aggregating and analyzing logs from different sources in a unified manner.

2. **Deployment Logging**: Ensure that every deployment action is logged. This includes the timestamp, the service being deployed, version number, deployment environment, and the individual initiating the deployment.

3. **Change Tracking**: Log all changes made to the microservices, such as configuration changes, updates to service endpoints, and changes in inter-service communication protocols.

4. **Automated Logging**: Integrate logging into the CI/CD pipeline to automate the logging of deployment and change events, ensuring consistency and reducing manual intervention.

5. **Visualization and Alerts**: Provide tools to visualize logs and set up alerts for specific events or patterns, aiding in proactive monitoring and issue resolution.

**References:**
- [Microservices Patterns](https://microservices.io/patterns/observability/log-deployments-and-changes.html)
- [Project Contribution Guidelines](https://github.com/iluwatar/java-design-patterns/wiki)

**Acceptance Criteria:**

1. A centralized logging system is implemented and integrated with all microservices.
2. Deployment actions are automatically logged with all necessary details.
3. All changes to microservices are logged, including configuration changes and updates.
4. The CI/CD pipeline is updated to include automated logging for deployments and changes.
5. Tools for log visualization and alerting are implemented and operational.
6. Documentation is updated to reflect the new logging mechanisms and usage instructions.
7. Unit and integration tests are written to ensure logging functionality works as expected.
Repository: java-design-patterns
Issue: Microservice pattern: Server-side page fragment composition
Labels: epic: pattern,type: feature

**Description:**

The Server-Side Page Fragment Composition design pattern involves composing a webpage from various fragments that are managed by different microservices. This pattern is particularly useful for creating modular, scalable web applications where each part of the page can be developed, deployed, and scaled independently. The key elements of this pattern include:

1. **Fragment Composition**: The server assembles the final webpage by composing various page fragments delivered by different microservices.
2. **Microservices**: Each page fragment is managed by a separate microservice, responsible for rendering that specific fragment.
3. **Scalability and Independence**: Each microservice can be developed, deployed, and scaled independently, enhancing the flexibility and maintainability of the application.
4. **Performance Optimization**: By assembling the page on the server-side, the pattern can optimize performance by reducing the load on the client and improving response times.
5. **Consistent User Experience**: Ensures a consistent user experience by composing fragments into a cohesive webpage.

**References:**
- [Server-Side Page Fragment Composition](https://microservices.io/patterns/server-side-fragment-composition.html)
- [Project Contribution Guidelines](https://github.com/iluwatar/java-design-patterns/wiki)

**Acceptance Criteria:**
1. Implement a demo project illustrating the Server-Side Page Fragment Composition design pattern.
2. Create separate microservices for different page fragments (e.g., header, footer, main content).
3. Implement a server-side composition service to assemble the final webpage from these fragments.
4. Ensure that each microservice can be independently developed, deployed, and scaled.
5. Provide comprehensive documentation and examples demonstrating the use of this pattern.
6. Adhere to the project contribution guidelines outlined in the [wiki](https://github.com/iluwatar/java-design-patterns/wiki).
Repository: rust
Issue: EnumSizeOpt changes behavior based on the host
Labels: T-compiler,C-bug,A-mir-opt

I ran into this test failure: https://github.com/rust-lang-ci/rust/actions/runs/6522096255/job/17711353756
```
  ---- [mir-opt] tests/mir-opt/enum_opt.rs stdout ----
  66	      }
  67	+ }
  68	+ 
  -	+ alloc15 (size: 8, align: 4) {
  +	+ alloc14 (size: 8, align: 4) {
  70	+     05 20 00 00 01 00 00 00                         │ . ......
  71	  }
  72	  
  
  thread '[mir-opt] tests/mir-opt/enum_opt.rs' panicked at src/tools/compiletest/src/runtest.rs:4091:21:
  Actual MIR output differs from expected MIR output /checkout/tests/mir-opt/enum_opt.unin.EnumSizeOpt.32bit.diff
```
This test failure only reproduces if the _host_ is 32-bit.

Reading over the code for this MIR transform, I found another bug:
https://github.com/rust-lang/rust/blob/d60d63fbf7565daba4b9cc46cbbfabc366aeff63/compiler/rustc_mir_transform/src/large_enums.rs#L74
This is comparing against the hosts's `usize::MAX`. I tried changing this to compare against `u32::MAX` and that did not change the behavior of the test on a 64-bit host, so I believe this is a second bug.

I would not be surprised if there are more.
Repository: go
Issue: cmd/go: value of -buildmode in buildinfo can differ from what is used in build ID
Labels: help wanted,NeedsFix,GoCommand

<!--
Please answer these questions before submitting your issue. Thanks!
-->

### What version of Go are you using (`go version`)?

<pre>
$ go version
go version go1.21.3 linux/amd64
</pre>

### Does this issue reproduce with the latest release?

Yes

### What operating system and processor architecture are you using (`go env`)?

<details><summary><code>go env</code> Output</summary><br><pre>
$ go env
GO111MODULE=''
GOARCH='amd64'
GOBIN=''
GOCACHE='/home/capnspacehook/.cache/go-build'
GOENV='/home/capnspacehook/.config/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFLAGS=''
GOHOSTARCH='amd64'
GOHOSTOS='linux'
GOINSECURE=''
GOMODCACHE='/home/capnspacehook/go/pkg/mod'
GONOPROXY=''
GONOSUMDB=''
GOOS='linux'
GOPATH='/home/capnspacehook/go'
GOPRIVATE=''
GOPROXY='https://proxy.golang.org,direct'
GOROOT='/usr/local/go'
GOSUMDB='sum.golang.org'
GOTMPDIR=''
GOTOOLCHAIN='auto'
GOTOOLDIR='/usr/local/go/pkg/tool/linux_amd64'
GOVCS=''
GOVERSION='go1.21.1'
GCCGO='gccgo'
GOAMD64='v3'
AR='ar'
CC='gcc'
CXX='g++'
CGO_ENABLED='1'
GOMOD=''
GOWORK=''
CGO_CFLAGS='-O2 -g'
CGO_CPPFLAGS=''
CGO_CXXFLAGS='-O2 -g'
CGO_FFLAGS='-O2 -g'
CGO_LDFLAGS='-O2 -g'
PKG_CONFIG='pkg-config'
GOGCCFLAGS='-fPIC -m64 -pthread -Wl,--no-gc-sections -fmessage-length=0 -ffile-prefix-map=/tmp/go-build3246179384=/tmp/go-build -gno-record-gcc-switches'
</pre></details>

### What did you do?

<!--
If possible, provide a recipe for reproducing the error.
A complete runnable program is good.
A link on go.dev/play is best.
-->

Built two binaries from identical source code, passing `-buildmode=default` to the first and `-buildmode=exe` to the second.

### What did you expect to see?

Both binaries should be identical and have the same hash.

### What did you see instead?

The binaries hashes differed, though using `xbindiff` showed that the build ID was the only difference between them. It seems that the buildmode that is actually used is included in binaries build information (`exe` in both cases), but the exact value of `-buildmode` as passed to `go build` is used when creating the build ID. To make reproducing binaries easier I think the same buildmode value that is used in the embedded build information should be used when creating the build ID.

Currently it can be very difficult to tell what value of `-buildmode` was passed at build time when you only have a Go binary and no information on its build process. This change would make it easier to reproduce Go binaries using the embedded build information as a guide.
Repository: godot
Issue: When you pack a scene, save it, then unpack/load it the timer node stops working
Labels: topic:core,needs testing

### Godot version

4.1.2

### System information

Windows 11 4.1

### Issue description

When you pack a scene, save it, then unpack/load it the timer node stops working. I believe I could add code in that makes a new timer every time it is loaded but if the other one was about to timeout before it got packed it would be not in sync.

### Steps to reproduce

Make a 1 second timer in a scene then pack the scene using PackedScene. Save the scene to a file, load it again and the timer will not be going.

### Minimal reproduction project

N/A
Repository: Python
Issue: `pytest` warnings in builds
Labels: bug

### Repository commit

Doesn't matter

### Python version (python --version)

Python 3.12.0, the current version used in builds

### Dependencies version (pip freeze)

Doesn't matter

### Expected behavior

`pytest` runs with no (internal) warnings

### Actual behavior

Every build (see our Actions tab) has the following warnings:
```
/opt/hostedtoolcache/Python/3.12.0/x64/lib/python3.12/site-packages/coverage/report_core.py:115: CoverageWarning: Couldn't parse '/home/runner/work/Python/Python/config-3.py': No source for code: '/home/runner/work/Python/Python/config-3.py'. (couldnt-parse)
  coverage._warn(msg, slug="couldnt-parse")
/opt/hostedtoolcache/Python/3.12.0/x64/lib/python3.12/site-packages/coverage/report_core.py:115: CoverageWarning: Couldn't parse '/home/runner/work/Python/Python/config.py': No source for code: '/home/runner/work/Python/Python/config.py'. (couldnt-parse)
  coverage._warn(msg, slug="couldnt-parse")
```
I don't know what files these are, and I don't know what's causing these warnings to occur.
Repository: next.js
Issue: Using custom runtime breaks dynamic routes
Labels: bug,Runtime

### Link to the code that reproduces this issue

https://github.com/capJavert/nextjs-functions-break-dynamic-routes

### To Reproduce

1. Add serverless function with custom runtime (eg. [Go](https://vercel.com/docs/functions/serverless-functions/runtimes/go)) to your Next.js project
2. Add dynamic API routes to your Next.js app inside app directory (or old school dynamic routes through `/api/pages`
3. Deploy to Vercel

You will observe:
- custom runtime handler works [/api/hello](https://nextjs-functions-break-dynamic-routes-bp54lnl4k-capjavert.vercel.app/api/hello) ✅ 
- dynamic route [/api/users/:id](https://nextjs-functions-break-dynamic-routes-bp54lnl4k-capjavert.vercel.app/api/users/1) (created in app directory) does not work and returns 404 🔴 
- dynamic route [/api/posts/:id](https://nextjs-functions-break-dynamic-routes-bp54lnl4k-capjavert.vercel.app/api/posts/1) (created in pages directory) does not work and returns 404 🔴 

I also noticed api routes without dynamic segments work fine [/api/boo](https://nextjs-functions-break-dynamic-routes-bp54lnl4k-capjavert.vercel.app/api/boo).

Deployment summary also shows all the functions correctly:
<img width="1177" alt="image" src="https://github.com/vercel/next.js/assets/9803078/675f07b8-37ce-4e4e-8a4a-9b5e465ad2f5">


### Current vs. Expected behavior

When custom runtime is used inside top level `/api` directory Next.js dynamic routes break and show 404. 

Dynamic routes should work as expected.

### Verify canary release

- [X] I verified that the issue exists in the latest Next.js canary release

### Provide environment information

```bash
Operating System:
  Platform: darwin
  Arch: arm64
  Version: Darwin Kernel Version 23.0.0: Fri Sep 15 14:41:43 PDT 2023; root:xnu-10002.1.13~1/RELEASE_ARM64_T6000
Binaries:
  Node: 18.16.0
  npm: 9.5.1
  Yarn: 1.22.18
  pnpm: 8.6.3
Relevant Packages:
  next: 13.5.5-canary.16
  eslint-config-next: N/A
  react: 18.2.0
  react-dom: 18.2.0
  typescript: 5.1.3
Next.js Config:
  output: N/A
```


### Which area(s) are affected? (Select all that apply)

App Router, Middleware / Edge (API routes, runtime)

### Additional context

_No response_