Hello friends, in this post lets look into the issues we faced after integrating:
- Sessions for users (sign in functionality)
- Order, Order items models and the related code base
Check our Github actions failure cases here: https://github.com/MIRA-Designs/design_studio/actions/runs/14953772366/job/42006659413?pr=31
What is working?
- Rubocop linting checks
- Test cases – Fails
- Brakeman security scan – Pending
Why the issue?
I made a mistake of integrating the sessions with Order and Order items model (I used the help of Co-piolet for improvement). I have only written the test cases for sessions. Why I made this mistake? Because for last some days the development was not happening in our design_studio project. So I was curious to do so many things at a time and I cannot control myself 🙂
Now what’s next?
Let’s solve the test cases issues. First I cannot get ‘why this test cases for Rate limit issue is happening’. I have to research on this. I want to try Cursor – how it works with these kind of scenarios. Cursor provide me details about exact issue in our test cases and updated for me. I was happy that I saved some time.
Let’s see What is the findings of cursor:
The current test case has few issues:
- It’s testing for 11 attempts, but the rate limit is set to 10 attempts. We should test that the 11th attempt is rate limited, but also verify that the first 10 attempts work as expected.
- We should verify that the rate limiting is time-based (within 1 minute) by testing that after waiting, the rate limit resets.
Fix the test case:
Cursor updated the test case to properly test the rate limiting functionality. Here’s what the improved test does:
- First, it makes 10 attempts and verifies that each attempt gets the normal “invalid credentials” response
- Then it makes the 11th attempt and verifies that it gets rate limited with the “Try again later” message
- Finally, it uses Rails’ travel helper to move forward in time past the rate limit window (1 minute + 1 second) and verifies that the rate limit has been reset by making another attempt
This test now properly verifies:
- The rate limit threshold (10 attempts)
- The rate limit behavior (redirect with “Try again later” message)
- The rate limit duration (1 minute)
- The rate limit reset after the time window expires
The test is now more thorough and matches the actual implementation in the SessionsController.
Run the test case with the fix:
Failure:
SessionsControllerTest#test_should_rate_limit_login_attempts [test/controllers/sessions_controller_test.rb:34]:
--- expected
+++ actual
@@ -1 +1 @@
-"Try again later."
+"Try another email address or password."
the problem is that the rate limiting is happening at the controller level using rate_limit, but our test isn’t properly simulating real-world timing. Let me modify the test to ensure we’re making the requests within the 1-minute window and properly testing the rate limiting.
We fixed it and still the issues are not solved:
# Running:
F
Failure:
SessionsControllerTest#test_should_rate_limit_login_attempts [test/controllers/sessions_controller_test.rb:36]:
--- expected
+++ actual
@@ -1 +1 @@
-"Try again later."
+"Try another email address or password."
bin/rails test test/controllers/sessions_controller_test.rb:23
The issue may be with our SessionsController rate_limit directive. That is not working in test environment. I had this doubt. Let’s see what cursor tell us regarding this:
Looking at the SessionsController, the rate limiting is implemented using Rails’ rate_limit macro, but it seems the rate limiting might not be working as expected in the test environment. Let’s try to debug this by checking if we need to enable rate limiting in the test environment or if there’s a different approach needed.
Cursor suggested Rails cache setup and wipe out cache:
require "test_helper"
class SessionsControllerTest < ActionDispatch::IntegrationTest
setup do
# Use memory store for rate limiting in tests
Rails.cache = ActiveSupport::Cache::MemoryStore.new
end
teardown do
Rails.cache.clear
end
......
The test environment is configured to use :null_store for caching, which means rate limiting won’t work. Let’s modify the test environment configuration:
environments/test.rb:
- config.cache_store = :null_store
+ config.cache_store = :memory_store
Cursor made two important changes:
- Changed the test environment’s cache store from :null_store to :memory_store to ensure rate limiting works properly
- Added a consistent IP address in the test requests using
headers: { REMOTE_ADDR: “192.168.1.1” }
since rate limiting is typically done based on the client’s IP address
The test should now work correctly because:
- We have proper caching enabled in the test environment
- We’re using a consistent IP address for all requests, which is what rate limiting typically uses to track requests
- We’re still maintaining the time window with travel_to and travel
- The cache is cleared between tests to ensure a clean state
Try running the test again – it should now properly detect when the rate limit is exceeded on the 11th request.
Running 5 tests in a single process (parallelization threshold is 50)
Run options: --seed 55394
# Running:
.
Finished in 1.222473s, 0.8180 runs/s, 28.6305 assertions/s.
1 runs, 35 assertions, 0 failures, 0 errors, 0 skips
Coverage report generated for Unit Tests to /Users/abhilash/rails/design_studio/public/coverage.
Line Coverage: 21.37% (81 / 379)
Works!! Cursor – you beauty.
Let us see why the fix worked:
- The main issue was that the test environment was using :null_store for caching, which effectively disabled all caching. Since Rails’ rate limiting feature relies on caching to track request counts, it wasn’t working properly.
- By changing to :memory_store, we enabled proper caching in the test environment, allowing the rate limiting to track requests.
- Adding the consistent IP address (REMOTE_ADDR: “192.168.1.1”) in the test requests was also important because Rails’ rate limiting typically uses the client’s IP address as part of the cache key to track requests per client.
- The test structure ensures clean state by:
- Using setup to initialize a fresh cache store for each test
- Using teardown to clear the cache after each test
- Using travel_to to ensure consistent timing for rate limit windows
- Using consistent IP addresses for request tracking
This is a good example of how testing rate limiting requires careful consideration of the entire environment, including caching, timing, and request attributes. The test now properly verifies that:
- Users can make up to 10 attempts within a minute
- The 11th attempt gets rate limited
- After waiting for a minute, they can try again
I may need some more time to get the fact that: “Rails’ rate limiting feature relies on caching to track request counts”. Here is the importance of AI tool like cursor. It saved a lot of my debugging time.
The Rails Drop 