Skip to content

feat: add irisopenapi adapter#60

Merged
akfaiz merged 1 commit into
mainfrom
feat/add-irisopenapi-adapter
May 11, 2026
Merged

feat: add irisopenapi adapter#60
akfaiz merged 1 commit into
mainfrom
feat/add-irisopenapi-adapter

Conversation

@akfaiz
Copy link
Copy Markdown
Member

@akfaiz akfaiz commented May 11, 2026

Description

add irisopenapi adapter

Type of Change

  • Bug fix
  • New feature
  • Breaking change
  • Documentation update
  • Refactor / code quality
  • Other (describe):

Checklist

  • make check passes locally (sync + tidy + lint + test)
  • Tests added or updated to cover the change
  • Golden files updated if spec output changed (make test-update)
  • Relevant documentation updated (README, adapter README, etc.)
  • Commit messages follow Conventional Commits

Notes for Reviewers

Breaking Change Notes

@codecov
Copy link
Copy Markdown

codecov Bot commented May 11, 2026

Codecov Report

❌ Patch coverage is 91.48936% with 8 lines in your changes missing coverage. Please review.

Files with missing lines Patch % Lines
adapter/irisopenapi/route.go 52.94% 6 Missing and 2 partials ⚠️

📢 Thoughts on this report? Let us know!

Copy link
Copy Markdown

@llamapreview llamapreview Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

AI Code Review by LlamaPReview

🎯 TL;DR & Recommendation

Recommendation: Approve with suggestions

This PR introduces a new Iris adapter for OpenAPI spec generation, following the established adapter patterns with solid test coverage. Two minor maintainability suggestions are noted below that do not block approval but improve future-proofing.

📄 Documentation Diagram

This diagram documents the Iris adapter's route registration and spec generation flow.

sequenceDiagram
participant User
participant Adapter as irisopenapi
participant IrisParty as Iris Party
participant SpecGen as spec.Generator

User->>Adapter: NewRouter(party, opts)
note over Adapter: PR #35;60: New Iris adapter
Adapter->>IrisParty: register docs endpoints
Adapter->>SpecGen: create spec router
User->>Adapter: Get("/ping", handler)
Adapter->>IrisParty: party.Handle(...)
Adapter->>SpecGen: specRouter.Add("GET","/ping")
User->>Adapter: GenerateSchema()
Adapter->>SpecGen: gen.GenerateSchema()
SpecGen-->>User: schema bytes
Loading

🌟 Strengths

  • Comprehensive test coverage including golden file testing for petstore example.
  • Clean separation of concerns following the existing adapter architecture.

💡 Suggestions

  • adapter/irisopenapi/route.go: Coupling to internal Iris type irisrouter.Route creates a latent risk of breakage on future Iris upgrades.
  • adapter/irisopenapi/route.go: Ignoring the return value of specRoute.With may cause applied OpenAPI options to be silently lost if the underlying implementation changes.

💡 Have feedback? We'd love to hear it in our GitHub Discussions.
✨ This review was generated by LlamaPReview Advanced, which is free for all open-source projects. Learn more.

Comment on lines +10 to +13
type route struct {
irisRoute *irisrouter.Route
specRoute spec.Route
}
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 | Confidence: High

The route struct stores a pointer to irisrouter.Route, which is an internal type of the Iris framework (github.com/kataras/iris/v12/core/router). This creates a tight coupling to an internal API that is not covered by Go module compatibility guarantees. While this pattern is shared across all existing adapters, it introduces a latent risk of breakage on minor Iris version upgrades where internal types may change. If the internal struct is altered in a future Iris release, the adapter will fail to compile and require a patch. A more robust approach would be to use only the public iris.Route interface if it exposes the needed fields (Method, Path, Name) or to define a thin wrapper that extracts these values at registration time.

return r.irisRoute.Name
}

func (r *route) With(opts ...option.OperationOption) Route {
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 | Confidence: Medium

The With method calls r.specRoute.With(opts...) but ignores its return value. If specRoute.With returns a new route (immutable pattern) rather than mutating in place, then r.specRoute would remain unchanged, causing the applied OpenAPI options to be silently lost. Based on the implementation of other adapters in this repository, it is likely that specRoute.With mutates the receiver. However, the ignored return value is a code smell and a potential future bug if the underlying implementation changes. For idiomatic safety and consistency with Go chaining practices, the result should be reassigned to r.specRoute. This is a defensive improvement that eliminates the risk entirely without performance cost.

Suggested change
func (r *route) With(opts ...option.OperationOption) Route {
func (r *route) With(opts ...option.OperationOption) Route {
if r.specRoute == nil {
return r
}
r.specRoute = r.specRoute.With(opts...)
return r
}

@akfaiz akfaiz merged commit 77e42ea into main May 11, 2026
6 checks passed
@akfaiz akfaiz deleted the feat/add-irisopenapi-adapter branch May 11, 2026 00:52
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant