This note comes from my first contribution to the Padrino framework.
The bug was small, but the workflow mattered. Isolate the behavior, reproduce it with a minimal case, find the failing assumption, and send a focused fix.
The symptom
Padrino allowed default values to be configured in a controller and then used when building URLs.
The application had a route with a default provider.
module Padre
App.controller provider: "google" do
get :index, map: "/:provider/index" do
end
end
end
Calling the URL helper without a provider should use the default. Calling it with an explicit provider should use the explicit value.
That second case failed.
The failing expectation
The existing tests already covered default values. The missing assertion was the override case.
assert_equal "/pt", @app.url(:index, lang: "pt")
Instead, the framework returned the default value.
Expected: "/pt"
Actual: "/it"
That made the problem clear. Defaults were being applied, but explicit parameters were not winning.
The root cause
The relevant code merged parameters in the wrong direction.
params = params.merge(@default_values) if @default_values.is_a?(Hash)
That gives default values priority over values passed by the caller.
The merge needed to be reversed so defaults fill gaps without overriding explicit input.
Why this kind of contribution works
Small framework fixes are easier to review when the report includes:
- a minimal reproduction.
- a failing test.
- a small patch.
- a clear explanation of the expected behavior.
The pull request did not need a broad refactor. It needed to correct one contract and prove the contract with a test.
That is the lesson from this contribution.
Open source maintainers are more likely to accept small, well-isolated fixes that reduce their investigation cost.