[TT-15505] Remove negate field as mandatory from the OAS API schema

[lghiur]

User description

TT-15505

Summary	Fix URL Rewrite Middleware Schema breaking change introduced in 5.8.3 and 5.9.0
Type	Bug
Status	In Dev
Points	N/A
Labels	jira_escalated

---

Description

Make negate field optional in URL rewrite schema

The negate field was previously made mandatory in the OAS API schema, which broke existing API definitions that don't have the negate field defined. This prevented customers from updating their APIs.

This change:

• Removes negate from required fields in both OAS schema files
• Adds omitempty tags to the URLRewriteRule struct to handle optional
  negate field
• Restores backward compatibility with existing API definitions

Fixes breaking change introduced in previous release where customers with API definitions lacking negate field could not update their APIs.

Related Issue

Motivation and Context

How This Has Been Tested

Screenshots (if appropriate)

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Refactoring or add test (improvements in base code or adds test coverage to functionality)

Checklist

• I ensured that the documentation is up to date
• I explained why this PR updates go.mod in detail with reasoning why it's required
• I would like a code coverage CI quality gate exception and have explained why

---

PR Type

Bug fix, Enhancement

---

Description

• Make negate field optional in URL rewrite schema

• Remove negate from required fields in OAS schema files

• Add omitempty to Negate in URLRewriteRule struct

• Restore backward compatibility for existing API definitions

---

Diagram Walkthrough

flowchart LR
  schemaOld["OAS Schema: 'negate' required"] -- "remove from required" --> schemaNew["OAS Schema: 'negate' optional"]
  structOld["Go Struct: 'negate' mandatory"] -- "add omitempty" --> structNew["Go Struct: 'negate' optional"]
  schemaNew -- "restores compatibility" --> compatibility["Backward Compatibility"]

Loading

File Walkthrough

	Relevant files
Enhancement	url_rewrite.go Make `Negate` field optional in Go struct                                apidef/oas/url_rewrite.go Add omitempty to Negate field in URLRewriteRule struct Make Negate optional in Go struct serialization +1/-1
Bug fix	x-tyk-api-gateway.json Remove `negate` from required fields in OAS schema              apidef/oas/schema/x-tyk-api-gateway.json Remove negate from required fields in two schema definitions Make negate field optional in OAS schema +2/-4      x-tyk-api-gateway.strict.json Remove `negate` from required fields in strict OAS schema apidef/oas/schema/x-tyk-api-gateway.strict.json Remove negate from required fields in two strict schema definitions Make negate field optional in strict OAS schema +2/-4

---

[buger]

Knock Knock! 🔍

Just thought I'd let you know that your PR title and story title look quite different. PR titles that closely resemble the story title make it easier for reviewers to understand the context of the PR.

An easy-to-understand PR title a day makes the reviewer review away! 😛⚡️

Story Title	Fix URL Rewrite Middleware Schema breaking change introduced in 5.8.3 and 5.9.0
PR Title	[TT-15505] Remove `negate` field as mandatory from the OAS API schema

Check out this guide to learn more about PR best-practices.

[github-actions]

PR Reviewer Guide 🔍

Here are some key observations to aid the review process:

⏱️ Estimated effort to review: 2 🔵🔵⚪⚪⚪

🧪 No relevant tests

🔒 No security concerns identified

⚡ Recommended focus areas for review Backward Compatibility The negate field is now optional in the Go struct and the OpenAPI schema. Reviewers should check if there are any code paths or consumers that expect negate to always be present, and ensure that omitting it does not cause unintended behavior or panics. Negate bool `bson:"negate,omitempty" json:"negate,omitempty"` Schema Consistency The removal of negate from the required fields in multiple schema definitions should be validated for consistency across all usages and documentation, to avoid schema drift or validation errors. "pattern" ]

[github-actions]

PR Code Suggestions ✨

No code suggestions found for the PR.

[github-actions]

API Changes

--- prev.txt	2025-08-08 06:10:30.648730902 +0000
+++ current.txt	2025-08-08 06:10:20.929583051 +0000
@@ -4746,7 +4746,7 @@
 
 	// Negate is a boolean negation operator. Setting it to true inverts the matching behaviour
 	// such that the rewrite will be triggered if the value does not match the `pattern` for this rule.
-	Negate bool `bson:"negate" json:"negate"`
+	Negate bool `bson:"negate,omitempty" json:"negate,omitempty"`
 }
     URLRewriteRule represents a rewrite
     matching rules. Tyk classic API definition:

[github-actions]

Error during chat processing: Error: Failed to get response from AI model during iteration 2. terminated

---

Tip: Mention me again using /security <request>.
Powered by Probe AI
Security Impact Reviewer Prompt

[github-actions]

🚦 Connectivity Review Snapshot

Effort	Tests	Security	Perf	TL;DR
🔵⚪⚪	✅	🔒 none	🟢	Making negate field optional restores backward compatibility without affecting connectivity

## Connectivity Assessment

• Redis Connections: No impact on Redis connectivity. URL rewrite rules are part of API definitions stored in Redis, but the change only affects schema validation, not storage or retrieval mechanisms.
• RPC Connections: No impact on RPC connections. The change doesn't modify any RPC-related code paths or message formats.
• Synchronization Mechanisms: No changes to how API definitions are synchronized between nodes. The PR simply makes a field optional in the schema.

## Test Coverage Validation

• Redis Tests: Existing tests for API definition storage and retrieval remain valid as the change is backward compatible.
• RPC Tests: No RPC-specific tests needed as the change doesn't affect RPC communication.
• Failure Scenario Tests: The PR actually fixes a failure scenario where API definitions without the negate field couldn't be updated.

## Security & Performance Impact

• Authentication Changes: None. The change doesn't affect authentication mechanisms.
• Performance Considerations: Negligible impact. Making a field optional in the schema doesn't affect runtime performance.
• Error Handling: Improves error handling by preventing validation errors for API definitions that don't include the negate field.

## Summary & Recommendations

• The PR correctly addresses a backward compatibility issue by making the negate field optional in both the Go struct and OAS schema.
• The change is minimal and focused, only modifying schema validation without affecting connectivity mechanisms.
• No suggestions to provide – change LGTM.

---

Tip: Mention me again using /connectivity <request>.
Powered by Probe AI
Connectivity Issues Reviewer Prompt for Tyk Gateway

[github-actions]

🚀 Performance Snapshot

Effort	Perf Risk	Hot Paths	Benchmarks	TL;DR
Low	🟢	✅	❔	Making negate optional has negligible performance impact

## Performance Impact Analysis

This change makes the negate field optional in URL rewrite schema by removing it from required fields in OAS schema files and adding omitempty tags to the Go struct. The performance impact is minimal as it only affects schema validation and JSON serialization/deserialization, not runtime behavior.

## Critical Areas

The URL rewrite middleware's core functionality is unaffected. When negate is omitted, it defaults to false (zero value for bool), maintaining the expected behavior where URL rewrite rules match when patterns match without negation. This preserves backward compatibility with existing API definitions.

## Optimization Recommendations

No optimizations needed. The change correctly addresses the backward compatibility issue without introducing performance regressions. The StringRegexMap.Check() method will continue to work as expected with the default false value when the field is omitted.

## Summary

• Making negate optional is a schema-level change with no runtime performance impact
• Default behavior (false) is preserved when field is omitted
• Memory usage might slightly improve for API definitions not using negation due to omitempty
• No suggestions to provide – change LGTM.

---

Tip: Mention me again using /performance <request>.
Powered by Probe AI
Performance Impact Reviewer Prompt

[github-actions]

📦 Impact Review Snapshot

Effort	Downstream Updates	Compatibility	Docs	TL;DR
Low	✅	🟢	📖	Making negate field optional restores backward compatibility with existing API definitions

## Impact Assessment

This PR fixes a backward compatibility issue by making the negate field optional in URL rewrite rules. The changes are focused on:

1. Adding omitempty to the Negate field in the URLRewriteRule struct in apidef/oas/url_rewrite.go
2. Removing negate from required fields in OAS schema definitions in both x-tyk-api-gateway.json and x-tyk-api-gateway.strict.json

These changes restore compatibility with existing API definitions that don't have the negate field defined, which is particularly important for customers upgrading from versions prior to 5.8.3/5.9.0 where this breaking change was introduced.

The impact on downstream repositories is minimal since this is a backward compatibility fix that makes a previously mandatory field optional, rather than introducing new functionality.

## Required Updates

No immediate updates are required in downstream repositories as this change is backward compatible:

1. tyk-operator: No changes needed as this PR makes the field optional rather than removing it. The operator will continue to work with both API definitions that include or omit the negate field.

2. tyk-charts: No changes needed as this is a schema change that doesn't affect configuration or deployment.

3. portal: No changes needed as the Portal will now correctly handle API definitions with or without the negate field.

4. tyk-sink (MDCB): No changes needed as this change maintains compatibility with existing API definitions.

## Compatibility Concerns

This PR actually resolves a compatibility issue rather than introducing one. By making the negate field optional:

1. Existing API definitions without the negate field will now validate correctly against the schema
2. New API definitions can still include the negate field when needed
3. The default behavior (when negate is omitted) will be false, which matches the previous behavior before the field was made mandatory

The change is fully backward compatible and should not introduce any new issues.

## Summary & Recommendations

• This PR correctly addresses a backward compatibility issue by making the negate field optional in URL rewrite rules
• The change is well-scoped and focused on fixing just the compatibility issue
• No downstream repository updates are required as this is a backward-compatible change
• Consider adding a note in the release notes to highlight this fix for customers who may have encountered issues with URL rewrite rules in versions 5.8.3 and 5.9.0

No suggestions to provide – change LGTM.

---

Tip: Mention me again using /dependency <request>.
Powered by Probe AI
Tyk Gateway Dependency Impact Reviewer

[github-actions]

🛡️ Security Snapshot

Effort	Risk Level	Tests	Compliance	TL;DR
Low	🟢	✅	✔️	Making negate field optional restores backward compatibility without introducing security risks

## Security Impact Analysis

This PR makes the negate field optional in URL rewrite rules by adding omitempty tags to the struct field and removing it from required fields in OAS schema files. The change is purely schema-related and doesn't alter the runtime behavior of URL rewrite functionality. When the field is omitted, it defaults to false (zero value for boolean), which maintains the expected behavior where URL rewrite rules match when patterns match without negation.

## Identified Vulnerabilities

No vulnerabilities were identified. The change:

• Doesn't modify any security-sensitive code paths
• Maintains the same validation logic for URL rewrite rules
• Preserves the expected default behavior when the field is omitted
• Doesn't introduce any new attack vectors or bypass opportunities

## Security Recommendations

No security-specific recommendations are necessary. The implementation correctly handles the optional field by using Go's default zero value for booleans, which provides predictable behavior when the field is omitted.

## OWASP Compliance

This change doesn't impact OWASP compliance aspects:

• No input validation changes that could lead to injection attacks
• No authentication or authorization mechanism changes
• No sensitive data exposure risks
• No security misconfiguration introduced
• The URL rewrite functionality maintains its existing security properties

## Summary

No security issues identified – change LGTM.

---

Tip: Mention me again using /security <request>.
Powered by Probe AI
Security Impact Reviewer Prompt

[github-actions]

🚀 Performance Snapshot

Effort	Perf Risk	Hot Paths	Benchmarks	TL;DR
Low	🟢	✅	❔	Making negate field optional has negligible performance impact

## Performance Impact Analysis

This PR makes the negate field optional in URL rewrite schema by removing it from required fields in OAS schema files and adding omitempty tags to the Go struct. The performance impact is minimal as it only affects schema validation and JSON serialization/deserialization, not runtime behavior of the URL rewrite middleware.

## Critical Areas

The URL rewrite functionality is a critical path in request processing, but this change doesn't alter the core logic. When negate is omitted, it defaults to false (zero value for bool), maintaining the expected behavior where URL rewrite rules match when patterns match without negation. This preserves backward compatibility with existing API definitions.

## Optimization Recommendations

No optimizations needed. The change correctly addresses the backward compatibility issue without introducing performance regressions. The default behavior (false) when the field is omitted is appropriate and maintains the expected functionality of the URL rewrite middleware.

## Summary

• Making negate optional is a schema-level change with no runtime performance impact
• Default behavior (false) is preserved when field is omitted
• Memory usage might slightly improve for API definitions not using negation due to omitempty
• No suggestions to provide – change LGTM.

---

Tip: Mention me again using /performance <request>.
Powered by Probe AI
Performance Impact Reviewer Prompt

[github-actions]

🚦 Connectivity Review Snapshot

Effort	Tests	Security	Perf	TL;DR
🔵⚪⚪	✅	🔒 none	🟢	Making negate field optional restores backward compatibility without affecting connectivity

## Connectivity Assessment

• Redis Connections: No impact on Redis connectivity. URL rewrite rules are part of API definitions stored in Redis, but the change only affects schema validation, not storage or retrieval mechanisms.
• RPC Connections: No impact on RPC connections. The change doesn't modify any RPC-related code paths or message formats.
• Synchronization Mechanisms: No changes to how API definitions are synchronized between nodes. The PR simply makes a field optional in the schema.

## Test Coverage Validation

• Redis Tests: Existing tests for API definition storage and retrieval remain valid as the change is backward compatible.
• RPC Tests: No RPC-specific tests needed as the change doesn't affect RPC communication.
• Failure Scenario Tests: The PR actually fixes a failure scenario where API definitions without the negate field couldn't be updated.

## Security & Performance Impact

• Authentication Changes: None. The change doesn't affect authentication mechanisms.
• Performance Considerations: Negligible impact. Making a field optional in the schema doesn't affect runtime performance.
• Error Handling: Improves error handling by preventing validation errors for API definitions that don't include the negate field.

## Summary & Recommendations

• The PR correctly addresses a backward compatibility issue by making the negate field optional in both the Go struct and OAS schema.
• The change is minimal and focused, only modifying schema validation without affecting connectivity mechanisms.
• No suggestions to provide – change LGTM.

---

Tip: Mention me again using /connectivity <request>.
Powered by Probe AI
Connectivity Issues Reviewer Prompt for Tyk Gateway

[github-actions]

📦 Impact Review Snapshot

Effort	Downstream Updates	Compatibility	Docs	TL;DR
Low	✅	🟢	📖	Making negate field optional restores backward compatibility with existing API definitions

## Impact Assessment

This PR addresses a backward compatibility issue by making the negate field optional in URL rewrite rules. The changes involve:

1. Adding omitempty to the Negate field in the URLRewriteRule struct in apidef/oas/url_rewrite.go
2. Removing negate from required fields in the X-Tyk-URLRewriteRuleForRequestBody schema in both OAS schema files

These changes restore compatibility with existing API definitions that don't have the negate field defined, which is important for customers upgrading from versions prior to 5.8.3/5.9.0 where this breaking change was introduced.

The impact is minimal since this is a backward compatibility fix that makes a previously mandatory field optional, rather than introducing new functionality.

## Required Updates

No immediate updates are required in downstream repositories as this change is backward compatible:

1. tyk-operator: No changes needed as this PR makes the field optional rather than removing it. The operator will continue to work with both API definitions that include or omit the negate field.

2. tyk-charts: No changes needed as this is a schema change that doesn't affect configuration or deployment.

3. portal: No changes needed as the Portal will now correctly handle API definitions with or without the negate field.

4. tyk-sink (MDCB): No changes needed as this change maintains compatibility with existing API definitions.

## Compatibility Concerns

This PR actually resolves a compatibility issue rather than introducing one. By making the negate field optional:

1. Existing API definitions without the negate field will now validate correctly against the schema
2. New API definitions can still include the negate field when needed
3. The default behavior (when negate is omitted) will be false, which matches the previous behavior before the field was made mandatory

The change is fully backward compatible and should not introduce any new issues.

## Summary & Recommendations

• This PR correctly addresses a backward compatibility issue by making the negate field optional in URL rewrite rules
• The change is well-scoped and focused on fixing just the compatibility issue
• No downstream repository updates are required as this is a backward-compatible change
• Consider adding a note in the release notes to highlight this fix for customers who may have encountered issues with URL rewrite rules in versions 5.8.3 and 5.9.0

No suggestions to provide – change LGTM.

---

Tip: Mention me again using /dependency <request>.
Powered by Probe AI
Tyk Gateway Dependency Impact Reviewer

[github-actions]

Performance Impact Review: URL Rewrite Schema Fix

🚀 Performance Snapshot

Effort	Perf Risk	Hot Paths	Benchmarks	TL;DR
Low	🟢	✅	❔	Making negate field optional has negligible performance impact

## Performance Impact Analysis

This PR makes the negate field optional in URL rewrite schema by removing it from required fields in OAS schema files and adding omitempty tags to the Go struct. The performance impact is minimal as it only affects schema validation and JSON serialization/deserialization, not runtime behavior of the URL rewrite middleware.

When the negate field is omitted, it defaults to false (Go's zero value for boolean), which maintains the expected behavior where URL rewrite rules match when patterns match without negation. This change is purely schema-related and doesn't alter the core functionality.

## Critical Areas

The URL rewrite middleware is part of the request processing path, but this change doesn't affect its runtime behavior. The StringRegexMap.FindStringSubmatch method, which implements the actual pattern matching logic with negation support, will continue to work as expected with the default false value when the field is omitted.

The change is well-contained to schema validation and struct serialization/deserialization, avoiding any impact on critical request processing paths. The URL rewrite functionality will maintain its current performance characteristics.

## Optimization Recommendations

No optimizations are needed for this change. The PR correctly addresses the backward compatibility issue by making the negate field optional in both the Go struct and OAS schema files. The default behavior (false) when the field is omitted is appropriate and maintains the expected functionality.

The implementation correctly leverages Go's zero value semantics for booleans, which is an efficient approach for handling optional boolean fields. No additional runtime checks or special handling is required.

## Summary

• Making negate optional is a schema-level change with no runtime performance impact
• Default behavior (false) is preserved when field is omitted, maintaining backward compatibility
• The change doesn't affect the core URL rewrite middleware functionality
• Memory usage might slightly improve for API definitions not using negation due to omitempty
• No suggestions to provide – change LGTM.

---

Tip: Mention me again using /performance <request>.
Powered by Probe AI
Performance Impact Reviewer Prompt

[github-actions]

🚦 Connectivity Review Snapshot

Effort	Tests	Security	Perf	TL;DR
🔵⚪⚪	✅	🔒 none	🟢	Making negate field optional restores backward compatibility without affecting connectivity

## Connectivity Assessment

• Redis Connections: No impact on Redis connectivity. The change only affects JSON serialization/deserialization of API definitions stored in Redis, not the connection mechanisms themselves.
• RPC Connections: No impact on RPC connections. The change doesn't modify any RPC protocol or connection handling code, only the structure of data being transmitted.
• Synchronization Mechanisms: No changes to how API definitions are synchronized between nodes. The PR simply makes a field optional in the schema.

## Test Coverage Validation

• Redis Tests: Existing tests for API definition storage and retrieval remain valid as the change is backward compatible.
• RPC Tests: No RPC-specific tests needed as the change doesn't affect RPC communication protocols.
• Failure Scenario Tests: The PR actually fixes a failure scenario where API definitions without the negate field couldn't be updated.

## Security & Performance Impact

• Authentication Changes: None. The change doesn't affect authentication mechanisms.
• Performance Considerations: Negligible impact. Making a field optional in the schema doesn't affect runtime performance.
• Error Handling: Improves error handling by preventing validation errors for API definitions that don't include the negate field.

## Summary & Recommendations

• The PR correctly addresses a backward compatibility issue by making the negate field optional in both the Go struct and OAS schema.
• When the field is omitted, it defaults to false (zero value for bool), maintaining the expected behavior for URL rewrite rules.
• The change is minimal and focused, only modifying schema validation without affecting connectivity mechanisms.
• No suggestions to provide – change LGTM.

---

Tip: Mention me again using /connectivity <request>.
Powered by Probe AI
Connectivity Issues Reviewer Prompt for Tyk Gateway

[github-actions]

PR Analysis: Making negate Field Optional in URL Rewrite Schema

This PR addresses a backward compatibility issue introduced in Tyk Gateway versions 5.8.3 and 5.9.0, where the negate field was made mandatory in URL rewrite rules. This change broke existing API definitions that didn't include this field, preventing customers from updating their APIs.

Changes Overview

The PR makes three specific changes:

1. Go Struct Change: Adds omitempty to the Negate field in the URLRewriteRule struct:

   // Before
   Negate bool `bson:"negate" json:"negate"`
   
   // After
   Negate bool `bson:"negate,omitempty" json:"negate,omitempty"`

2. Schema Changes: Removes negate from the required fields list in both schema files:

   • apidef/oas/schema/x-tyk-api-gateway.json
   • apidef/oas/schema/x-tyk-api-gateway.strict.json

Impact Analysis

• Backward Compatibility: This change restores compatibility with existing API definitions that don't have the negate field defined.
• Default Behavior: When the field is omitted, it defaults to false (Go's zero value for booleans), maintaining the expected behavior where URL rewrite rules match when patterns match without negation.
• API Validation: API definitions without the negate field will now pass schema validation.

Security & Performance

• Security: No security concerns as this is a schema-level change that doesn't alter the core functionality.
• Performance: No performance impact as this only affects JSON serialization/deserialization and validation.

Recommendation

This PR correctly addresses the backward compatibility issue by making the negate field optional while maintaining the expected behavior. The change is minimal and focused on fixing just the compatibility issue without introducing new functionality or risks.

The PR should be approved as it resolves a customer-impacting issue in a clean and backward-compatible way.

---

Tip: Mention me again using /security <request>.
Powered by Probe AI
Security Impact Reviewer Prompt

[github-actions]

📦 Impact Review Snapshot

Effort	Downstream Updates	Compatibility	Docs	TL;DR
Low	✅	🟢	📖	Making negate field optional restores backward compatibility with existing API definitions

## Impact Assessment

This PR addresses a backward compatibility issue by making the negate field optional in URL rewrite rules. The changes involve:

1. Adding omitempty to the Negate field in the URLRewriteRule struct in apidef/oas/url_rewrite.go
2. Removing negate from required fields in the OAS schema files for both X-Tyk-URLRewriteRule and X-Tyk-URLRewriteRuleForRequestBody

These changes restore compatibility with existing API definitions that don't have the negate field defined, which is important for customers upgrading from versions prior to 5.8.3/5.9.0 where this breaking change was introduced.

The impact is minimal since this is a backward compatibility fix that makes a previously mandatory field optional, rather than introducing new functionality.

## Required Updates

No immediate updates are required in downstream repositories as this change is backward compatible:

1. tyk-operator: No changes needed as this PR makes the field optional rather than removing it. The operator will continue to work with both API definitions that include or omit the negate field.

2. tyk-charts: No changes needed as this is a schema change that doesn't affect configuration or deployment.

3. portal: No changes needed as the Portal will now correctly handle API definitions with or without the negate field.

4. tyk-sink (MDCB): No changes needed as this change maintains compatibility with existing API definitions.

## Compatibility Concerns

This PR actually resolves a compatibility issue rather than introducing one. By making the negate field optional:

1. Existing API definitions without the negate field will now validate correctly against the schema
2. New API definitions can still include the negate field when needed
3. The default behavior (when negate is omitted) will be false, which matches the previous behavior before the field was made mandatory

The change is fully backward compatible and should not introduce any new issues. When the negate field is omitted, it defaults to false (zero value for boolean), which maintains the expected behavior where URL rewrite rules match when patterns match without negation.

## Summary & Recommendations

• This PR correctly addresses a backward compatibility issue by making the negate field optional in URL rewrite rules
• The change is well-scoped and focused on fixing just the compatibility issue
• No downstream repository updates are required as this is a backward-compatible change
• Consider adding a note in the release notes to highlight this fix for customers who may have encountered issues with URL rewrite rules in versions 5.8.3 and 5.9.0

No suggestions to provide – change LGTM.

---

Tip: Mention me again using /dependency <request>.
Powered by Probe AI
Tyk Gateway Dependency Impact Reviewer

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[edsonmichaque]

LGTM

[lghiur]

/release to release-5.8

[lghiur]

/release to release-5.9

[lghiur]

/release to release-5.8.4

[tykbot]

Working on it! Note that it can take a few minutes.

[lghiur]

/release to release-5.9.1

[tykbot]

Working on it! Note that it can take a few minutes.

[tykbot]

Working on it! Note that it can take a few minutes.

[tykbot]

Working on it! Note that it can take a few minutes.

[tykbot]

@lghiur Created merge PRs

[tykbot]

@lghiur Seems like there is conflict and it require manual merge.

[tykbot]

Still working...

[tykbot]

Still working...

[tykbot]

@lghiur Seems like there is conflict and it require manual merge.

[tykbot]

@lghiur Created merge PRs