sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: react
Issue: Bug: performance deteriorates when using ReactDOM.createRoot instead of ReactDom.render for virtual-table.
Labels: Type: Needs Investigation

While experimenting with react-window, I encountered a performance disparity in my project compared to the smooth user experience demonstrated in the react-window documentation examples. Even after building for production, I noticed white flashes when scrolling quickly in my project, whereas the documentation's examples remained consistently smooth.

After conducting several experiments, I successfully identified the root cause: the performance significantly deteriorates when using ReactDOM.createRoot compared to the now deprecated ReactDOM.render.

Here is a video to illustrate the issue:
https://github.com/facebook/react/assets/7544804/0be9ba6f-47e8-4d61-bb6c-e8fef0787776

This issue is not exclusive to react-window; in fact, I first encountered it while developing a toy version of it using function components and hooks (react-window itself is currently implemented using class components).

React version:
Tried with react/react-dom 18.2.0 and react/react-dom 18.3.0-canary-09fbee89d-20231013

Link to code example:
Here are two CodeSandbox examples of the same scenario with only one distinction:
- The first one uses ReactDOM.render: https://codesandbox.io/s/modest-cdn-4jwd6y?file=/index.js 
- The second one uses ReactDOM.createRoot: https://codesandbox.io/s/magical-cdn-ggyytv?file=/index.js 
**It's worth noting that the issue seems to become more pronounced after building the React app for production.** I'm not sure if that's possible directly on codesandbox.

Additionally, I've created two CodeSandbox using my own simplified version of a virtual table, the performance issue is also noticeable in this scenario:
- Using ReactDom.render: https://codesandbox.io/s/sleepy-bardeen-43dd9g?file=/index.js
- Using ReactDom.createRoot: https://codesandbox.io/s/friendly-wilson-qxs4yc?file=/index.js

## The current behavior
The performance appears to be worse when using ReactDom.createRoot compared to ReactDom.render

## The expected behavior
Using ReactDom.createRoot should give the same performance or better performance than ReactDom.render
Repository: godot
Issue: Cannot animate rotation on inherited scenes, shows an error that Basis must be normalised
Labels: bug,topic:animation,topic:3d

### Godot version

v4.1.1

### System information

Godot v4.1.1.stable.mono - Windows 10.0.19045 - Vulkan (Forward+) - dedicated NVIDIA GeForce MX110 (NVIDIA; 31.0.15.3742) - Intel(R) Core(TM) i5-8250U CPU @ 1.60GHz (8 Threads)

### Issue description

When trying to animate the 3D rotation property of an inherited scene, it breaks and prints this error: 
![image](https://github.com/godotengine/godot/assets/39242060/17e85d58-7526-4cf2-8160-356f8be442b1)

Here I am trying to animate Light Bulb, however it says the Basis is not normalized. I have however attempted this with 2 other cases which worked. 

First one is animating a fresh node in a fresh scene that isn't inherited from anything: 

https://github.com/godotengine/godot/assets/39242060/b6387aa2-1be4-4ed2-9df3-fdf5bd31e0d9

And the second is animating a scene but its root node isn't inherited which for some reason worked: 

https://github.com/godotengine/godot/assets/39242060/c0390324-920c-4650-82c3-eb1e19c7eec2

What I expect is that when I attempt to animate the bulb, it behaves like it would in the last example but it doesn't


### Steps to reproduce

- Inherit a scene that contains multiple parts (preferably from a .glb)
- Add an animation player as a child of one of those parts
- Add a 3D rotation track
- Observe

### Minimal reproduction project

[Minimal Reproduction Project.zip](https://github.com/godotengine/godot/files/12909959/Minimal.Reproduction.Project.zip)
Repository: godot
Issue: [4.2.beta1] Editor: Missing Sky / Environment on scene reload 
Labels: bug,topic:rendering,topic:editor,topic:3d

### Godot version

4.2.beta1

### System information

Windows 10 - Godot 4.2.beta1

### Issue description

So i have discovered a rendering bug,  it doesn't seem to throw an error when it happens..  when opening the engine with a scene loaded it loads properly..  as show below. 

![42envworking](https://github.com/godotengine/godot/assets/1302391/5373a3fc-7e5e-45bc-be46-c97e4db590fa)


But if you close the scene and try to re-open it or sometimes even on save it loads with a missing environment/sky as show below. 


![42envnotworking](https://github.com/godotengine/godot/assets/1302391/a220f408-2d27-4a5b-93e3-13b3b63a6c94)


### Steps to reproduce

See Above **

### Minimal reproduction project

Will work on this if it is widespread,  I prefer reporting there is an issue so that others may add if they encounters it and thus leading towards a fix quicker.
Repository: java-design-patterns
Issue: Monolithic architecture
Labels: epic: pattern,type: feature

### Description:
The Monolithic Architecture design pattern structures an application as a single, unified codebase where all modules and components are tightly integrated and run as a single service. This pattern simplifies development, testing, and deployment processes, making it suitable for smaller teams and applications with straightforward requirements. 

Key elements of the Monolithic Architecture:
- **Single Codebase**: All the functionality of the application resides in a single code repository.
- **Tight Coupling**: Components are closely interconnected, making it easy to share code and data within the application.
- **Centralized Logic**: All business logic, data access, and user interfaces are housed in one application.
- **Unified Deployment**: The entire application is deployed as a single unit.

This pattern is advantageous for applications that do not require complex scaling and have limited functional scope.

### References:
- [Monolithic Architecture](https://martinfowler.com/bliki/Monolith.html)
- [Monolithic vs Microservices Architecture](https://microservices.io/patterns/monolithic.html)
- [GitHub Contribution Guidelines](https://github.com/iluwatar/java-design-patterns/wiki)

### Acceptance Criteria:
1. **Project Structure**: Create a new module following the project structure guidelines.
2. **Implementation**: Develop a simple monolithic application that incorporates all business logic, data access, and user interfaces within the single application.
3. **Functionality**: Ensure the application covers a basic but comprehensive use case that demonstrates the Monolithic Architecture effectively.
4. **Testing**: Write unit tests to cover key functionalities, ensuring robust test coverage.
5. **Documentation**: Provide a detailed README file explaining:
    - What the Monolithic Architecture is.
    - Use cases and scenarios where it is applicable.
    - How the provided example demonstrates the Monolithic Architecture pattern.
6. **Quality Assurance**: Ensure all existing and new tests pass successfully.
7. **Code Review**: Conduct a thorough code review to ensure the implementation adheres to the project's coding standards and best practices.
8. **References**: Include references to relevant documentation and external resources that explain the Monolithic Architecture in detail.
Repository: java-design-patterns
Issue: Microservice architecture
Labels: info: help wanted,epic: pattern,type: feature

### Description:
The Microservice Architecture pattern structures an application as a collection of loosely coupled services. This approach enhances modularity, allowing each service to be developed, deployed, and scaled independently. Key elements of this pattern include service granularity, decentralized data management, inter-service communication, and automated deployment pipelines.

Main Elements:
1. **Service Granularity**: Each microservice focuses on a specific business function.
2. **Decentralized Data Management**: Each service manages its own database.
3. **Inter-Service Communication**: Services interact through APIs, often using RESTful services or messaging queues.
4. **Automated Deployment**: Continuous integration and deployment pipelines ensure seamless updates and maintenance.
5. **Fault Isolation**: Each service is isolated to prevent system-wide failures.

### References:
- [Microservices](https://martinfowler.com/articles/microservices.html) by Martin Fowler
- [Building Microservices](https://www.oreilly.com/library/view/building-microservices/9781491950340/) by Sam Newman
- [Microservice Architecture](https://docs.microsoft.com/en-us/azure/architecture/guide/architecture-styles/microservices) on Microsoft Docs
- [Microservice architecture](https://microservices.io/patterns/microservices.html)

Acceptance Criteria:
1. Implementation of a minimum of three microservices, each handling a distinct business function.
2. Each microservice must have its own independent data storage solution.
3. Demonstrate inter-service communication using RESTful APIs or messaging systems.

For additional guidelines, please refer to the [project contribution guidelines](https://github.com/iluwatar/java-design-patterns/wiki).
Repository: java-design-patterns
Issue: Microservice pattern: Database per service
Labels: info: help wanted,epic: pattern,type: feature,status: stale

### Description:
The Microservices - Database per Service design pattern advocates for each microservice to have its own private database. This design pattern is crucial for achieving loose coupling between microservices, allowing each service to be developed, deployed, and scaled independently. Here are the main elements of this pattern:

1. **Service Independence**: Each microservice has its own database schema and database server. This isolation ensures that services do not interfere with each other’s data.
2. **Scalability**: Individual microservices can be scaled independently according to their specific data access and storage needs.
3. **Polyglot Persistence**: Different microservices can use different types of databases (SQL, NoSQL, etc.) based on their specific requirements.
4. **Data Consistency**: Ensuring eventual consistency through patterns like Saga or event sourcing is crucial since distributed transactions are not feasible.
5. **Security and Access Control**: Each microservice manages its own database security, ensuring data encapsulation and reducing the risk of unauthorized access.

### References:
- [Microservices Patterns: With examples in Java](https://www.amazon.com/Microservices-Patterns-examples-Chris-Richardson/dp/1617294543)
- [Martin Fowler on Microservice Architecture](https://martinfowler.com/articles/microservices.html)
- [Database per Service Pattern](https://microservices.io/patterns/data/database-per-service.html)
- [Project Contribution Guidelines](https://github.com/iluwatar/java-design-patterns/wiki)

### Acceptance Criteria:
1. **Design and Documentation**:
   - Clearly define the architecture diagram showing multiple microservices with their own databases.
   - Update project documentation to include details on the Database per Service pattern, its benefits, and challenges.
   
2. **Implementation**:
   - Implement a sample microservices application demonstrating the Database per Service pattern.
   - Each microservice should interact with its own separate database.
   - Demonstrate polyglot persistence by using at least two different types of databases.

3. **Testing**:
   - Write unit tests to ensure each microservice can independently access and manipulate its data.
   - Implement integration tests to validate data consistency across services using eventual consistency mechanisms.

4. **Example Scenario**:
   - Provide an example scenario (e.g., e-commerce application) where multiple services (e.g., Order, Product, User) have their own databases.
   - Show how these services interact with each other and maintain data consistency.
Repository: java-design-patterns
Issue: Microservice pattern: Shared database
Labels: info: help wanted,epic: pattern,type: feature

**Description:**
The Microservices - Shared Database design pattern involves multiple microservices sharing a single database schema. This pattern can be used to manage distributed data transactions and maintain data consistency across different microservices.

**Main elements of the pattern:**
- **Shared Database:** A single database is shared among multiple microservices.
- **Data Consistency:** Ensuring data consistency and integrity across microservices.
- **Transaction Management:** Handling distributed transactions efficiently.
- **Service Independence:** Maintaining the autonomy of each microservice while sharing a common data source.
- **Database Schema Design:** Careful design of the database schema to avoid tight coupling between microservices.
- **Security:** Implementing robust security measures to protect the shared data.
- **Scalability:** Ensuring that the shared database can handle the load from multiple microservices.

**References:**
1. [Project Contribution Guidelines](https://github.com/iluwatar/java-design-patterns/wiki)
2. Microservices Architecture Patterns - [Microservices.io](https://microservices.io/patterns/data/shared-database.html)
3. "Building Microservices" by Sam Newman
4. [Martin Fowler's Blog on Microservices](https://martinfowler.com/microservices/)
5. [Spring Cloud Documentation](https://spring.io/projects/spring-cloud)

**Acceptance Criteria:**
1. Create a new package for the Microservices - Shared Database design pattern within the project.
2. Implement a working example demonstrating the shared database pattern with at least two microservices.
3. Ensure that the example includes:
   - A shared database schema
   - Transaction management across microservices
   - Data consistency mechanisms
4. Include unit tests and integration tests to validate the functionality.
5. Provide comprehensive documentation explaining the implementation, including code comments and a README file in the package.
6. Ensure the implementation adheres to the project's contribution guidelines and coding standards.
Repository: java-design-patterns
Issue: Microservice pattern: Command-side replica
Labels: epic: pattern,type: feature

**Description:**
The Command-Side Replica design pattern in a microservices architecture focuses on creating replicas of the command side of the services to handle command requests more efficiently. This pattern is beneficial in scenarios where the command operations need to be highly available and scalable. By implementing command-side replicas, we ensure that the system can handle high loads and maintain performance and reliability.

**Main elements of the pattern:**
1. **Command Replication:** Creating multiple instances of the command service to distribute the load.
2. **Load Balancing:** Utilizing load balancers to distribute incoming command requests across the replicas.
3. **Consistency Management:** Ensuring that all replicas remain consistent, often using techniques like eventual consistency or distributed transactions.
4. **Fault Tolerance:** Implementing mechanisms to handle failures and ensure high availability of command services.

**References:**
1. [Microservices Patterns: With examples in Java](https://www.amazon.com/Microservices-Patterns-examples-Chris-Richardson/dp/1617294543)
2. [Designing Data-Intensive Applications](https://www.amazon.com/Designing-Data-Intensive-Applications-Reliable-Maintainable/dp/1449373321)
3. [Command-Side Replica Pattern](https://microservices.io/patterns/data/command-side-replica.html)
4. [Project Contribution Guidelines](https://github.com/iluwatar/java-design-patterns/wiki)

**Acceptance Criteria:**
1. A working implementation of the Command-Side Replica pattern with at least two replicas handling command requests.
2. Proper load balancing setup to distribute incoming requests across the replicas.
3. Documentation and unit tests demonstrating the functionality, consistency, and fault tolerance of the implemented pattern.
Repository: java-design-patterns
Issue: Microservice pattern: Domain event
Labels: epic: pattern,type: feature

### Description
The Microservices - Domain Event design pattern is used to achieve a reliable communication mechanism between microservices. This pattern ensures that different services can react to changes or events occurring in other services without needing to tightly couple their operations. By leveraging domain events, we can decouple services, ensuring scalability and maintainability.

#### Main Elements of the Pattern:
1. **Domain Events**: Represent significant state changes within a service that other services might be interested in.
2. **Event Publisher**: The component within a service that publishes the domain event to an event broker.
3. **Event Broker**: A middleware that handles the distribution of domain events to subscribing services.
4. **Event Subscriber**: The component within a service that subscribes to domain events and reacts accordingly.

#### Benefits:
- **Decoupling**: Services do not need to directly communicate with each other, promoting loose coupling.
- **Scalability**: Each service can be scaled independently.
- **Maintainability**: Changes in one service do not directly affect other services, making the system easier to maintain.

### References
1. [Microservices Architecture](https://martinfowler.com/microservices/)
2. [Domain Event Pattern](https://martinfowler.com/eaaDev/DomainEvent.html)
3. [Project Contribution Guidelines](https://github.com/iluwatar/java-design-patterns/wiki)
4. [Domain Event in Microservices](https://microservices.io/patterns/data/domain-event.html)

### Acceptance Criteria
1. Implement the Domain Event design pattern in the project, including event publishers and subscribers.
2. Ensure proper documentation and examples are provided for the implemented pattern.
3. Add unit tests to verify the correct functioning of the domain events, including publishing and subscribing mechanisms.
Repository: java-design-patterns
Issue: Microservice pattern: Transactional outbox
Labels: info: help wanted,epic: pattern,type: feature

**Description:**
The Transactional Outbox design pattern ensures reliable communication between microservices by storing messages in an outbox table as part of the same local transaction that modifies application data. This pattern helps to achieve eventual consistency in distributed systems by using a separate service or process to read the outbox table and send messages to a message broker.

**Main Elements of the Pattern:**
- **Outbox Table:** A dedicated table in the database where messages are stored as part of the same transaction that updates the application state.
- **Polling Service:** A service or process that periodically reads the outbox table and sends the messages to the appropriate message broker.
- **Idempotency:** Ensures that messages are processed only once, avoiding duplicate processing.
- **Error Handling and Retries:** Mechanisms to handle failures in message delivery and to retry sending messages until they succeed.
- **Message Broker:** A system like Kafka, RabbitMQ, etc., that acts as an intermediary to transmit messages between microservices.

**References:**
- [Transactional Outbox Pattern - Microservices Patterns](https://microservices.io/patterns/data/transactional-outbox.html)
- [Java Design Patterns Project Contribution Guidelines](https://github.com/iluwatar/java-design-patterns/wiki)

**Acceptance Criteria:**
1. Implement an outbox table to store messages within the local transaction of the application.
2. Develop a polling service to read messages from the outbox table and send them to a message broker.
3. Ensure idempotent message processing and robust error handling with retries for message delivery.
Repository: java-design-patterns
Issue: Microservice pattern: Transaction log tailing
Labels: info: help wanted,epic: pattern,type: feature

**Description:**
The Microservices - Transaction Log Tailing design pattern focuses on maintaining a consistent and up-to-date data view across different microservices by tailing the transaction log of a database. This pattern is particularly useful in scenarios where multiple microservices need to respond to changes in a shared database in real-time. It ensures that all services are notified of changes and can react accordingly without direct coupling.

**Main Elements:**
1. **Transaction Log:** The database maintains a log of all transactions. This log is used as the source of truth for all changes.
2. **Log Tailing:** A component tails the transaction log and publishes changes to a message broker or event stream.
3. **Event Stream:** Microservices subscribe to the event stream to receive updates.
4. **Consistency:** Ensures eventual consistency across different microservices by propagating changes through the event stream.
5. **Decoupling:** Reduces direct dependencies between microservices by using the transaction log as an intermediary.

**References:**
- [Microservices Pattern: Transaction Log Tailing](https://microservices.io/patterns/data/transaction-log-tailing.html)
- [Martin Fowler - Event-Driven Architecture](https://martinfowler.com/articles/201701-event-driven.html)
- [Project Contribution Guidelines](https://github.com/iluwatar/java-design-patterns/wiki)

**Acceptance Criteria:**
1. Implement a component that tails the transaction log of a database and publishes changes to an event stream.
2. Develop microservices that subscribe to the event stream and update their state based on the received events.
3. Ensure eventual consistency across all microservices by validating that updates are correctly propagated and handled.
Repository: java-design-patterns
Issue: Microservice pattern: Polling publisher
Labels: epic: pattern,type: feature

**Description:**
The Polling Publisher design pattern is used within microservices architecture to allow services to periodically check for updates or changes and then publish the results to subscribers. This pattern is particularly useful for ensuring that microservices are loosely coupled and can independently manage their data refresh cycles without requiring direct communication or immediate event-based updates.

**Main Elements of the Pattern:**
1. **Polling Service:** A microservice that periodically checks for updates or changes in a specific data source.
2. **Publisher:** The component within the polling service that publishes the updated data to interested subscribers.
3. **Subscriber:** Services or components that subscribe to the updates published by the polling service.
4. **Scheduler:** A mechanism to trigger the polling service at regular intervals.
5. **Data Source:** The source from which the polling service fetches updates.
6. **Communication Protocol:** Defines how the polling service communicates with subscribers, typically using RESTful APIs, message brokers, or other asynchronous messaging systems.

**References:**
- [Microservices Architecture](https://martinfowler.com/articles/microservices.html)
- [Polling and Event-Based Messaging in Microservices](https://microservices.io/patterns/data/polling-publisher.html)

**Acceptance Criteria:**
1. Implement a basic polling service that checks for updates in a predefined data source at regular intervals.
2. Ensure the polling service can publish updates to subscribers using a RESTful API or message broker.
3. Provide a sample subscriber that demonstrates how to consume updates from the polling service.