fix: postgres bulk insert issue

[georgehao]

Purpose or design rationale of this PR

Describe your change. Make sure to answer these three questions: What does this PR do? Why does it do it? How does it do it?

scroll repo will encounter: postgres will return extended protocol limited to 65535 parameters issue

Fix:

• Add a batch insert limit, gorm will automatically split it base on your limit

func main() {
	b, err := gorm.Open(postgres.Open("postgres://localhost/xx?sslmode=disable"), &gorm.Config{
		CreateBatchSize: 5,
		Logger:          logger.Default.LogMode(logger.Info),
	})
	if err != nil {
		return
	}

	challenges := []Challenge{
		{Challenge: "11"},
		{Challenge: "12"},
		{Challenge: "13"},
		{Challenge: "14"},
		{Challenge: "15"},
		{Challenge: "16"},
		{Challenge: "17"},
		{Challenge: "18"},
		{Challenge: "19"},
		{Challenge: "110"},
	}

	if err = b.Create(&challenges).Error; err != nil {
		panic(err)
	}
}

output:

2026/01/13 12:05:31 /Users/haohongfan-scroll/goproject/test/gorm/main.go:49
[4.301ms] [rows:5] INSERT INTO "challenge" ("challenge","created_at","updated_at","deleted_at") VALUES ('11','2026-01-13 12:05:31.661','2026-01-13 12:05:31.661',NULL),('12','2026-01-13 12:05:31.661','2026-01-13 12:05:31.661',NULL),('13','2026-01-13 12:05:31.661','2026-01-13 12:05:31.661',NULL),('14','2026-01-13 12:05:31.661','2026-01-13 12:05:31.661',NULL),('15','2026-01-13 12:05:31.661','2026-01-13 12:05:31.661',NULL) RETURNING "id"

2026/01/13 12:05:31 /Users/haohongfan-scroll/goproject/test/gorm/main.go:49
[0.192ms] [rows:5] INSERT INTO "challenge" ("challenge","created_at","updated_at","deleted_at") VALUES ('16','2026-01-13 12:05:31.665','2026-01-13 12:05:31.665',NULL),('17','2026-01-13 12:05:31.665','2026-01-13 12:05:31.665',NULL),('18','2026-01-13 12:05:31.665','2026-01-13 12:05:31.665',NULL),('19','2026-01-13 12:05:31.665','2026-01-13 12:05:31.665',NULL),('110','2026-01-13 12:05:31.665','2026-01-13 12:05:31.665',NULL) RETURNING "id"

PR title

Your PR title must follow conventional commits (as we are doing squash merge for each PR), so it must start with one of the following types:

• build: Changes that affect the build system or external dependencies (example scopes: yarn, eslint, typescript)
• ci: Changes to our CI configuration files and scripts (example scopes: vercel, github, cypress)
• docs: Documentation-only changes
• feat: A new feature
• fix: A bug fix
• perf: A code change that improves performance
• refactor: A code change that doesn't fix a bug, or add a feature, or improves performance
• style: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)
• test: Adding missing tests or correcting existing tests

Deployment tag versioning

Has tag in common/version.go been updated or have you added bump-version label to this PR?

• No, this PR doesn't involve a new deployment, git tag, docker image tag
• Yes

Breaking change label

Does this PR have the breaking-change label?

• No, this PR is not a breaking change
• Yes

Summary by CodeRabbit

• Bug Fixes

  • Out-of-range pagination requests now return empty cached results instead of triggering a miss path.

• Performance

  • Increased database batch processing size for more efficient bulk operations.

• Chores

  • Updated release version to v4.7.11.

_{✏️ Tip: You can customize this high-level summary in your review settings.}

[coderabbitai]

📝 Walkthrough

Walkthrough

Three small changes: cache paging logic now treats out-of-range pages as hits with empty results; GORM DB config sets CreateBatchSize to 1000; version tag bumped from v4.7.10 to v4.7.11.

Changes

Cohort / File(s)	Summary
Cache Hit Logic bridge-history-api/internal/logic/history_logic.go	getCachedTxsInfo now returns isHit = true when the requested page start index is >= total items, so out-of-range page requests are treated as cache hits with empty results.
Database Configuration common/database/db.go	Added CreateBatchSize: 1000 to the GORM configuration in InitDB, added before the logger assignment.
Version Bump common/version/version.go	Updated the version tag from v4.7.10 to v4.7.11, affecting the computed Version value.

Sequence Diagram(s)

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

Possibly related PRs

• Return when total < request page #1766 — Related change in getCachedTxsInfo paging handling; differs in whether out-of-range pages are treated as cache hit (this PR) or as a miss.

Suggested reviewers

• yiweichi
• Thegaram

Poem

🐰 A hop, a tweak, a gentle cheer,
Out-of-bounds pages now disappear,
Batches of a thousand hop in line,
Version nudged up — looking fine,
A rabbit pats the code, "All clear!" 🥕

🚥 Pre-merge checks | ✅ 3

✅ Passed checks (3 passed)

Check name	Status	Explanation
Title check	✅ Passed	The PR title 'fix: postgres bulk insert issue' directly aligns with the main change: adding CreateBatchSize to GORM config to fix postgres bulk insert parameter limits.
Description check	✅ Passed	The description explains what the PR does, why it's needed (postgres extended protocol limit), and how it fixes it (CreateBatchSize config with example). However, the version bump checkbox is marked 'Yes' but the tag was actually updated, creating ambiguity about intent.
Docstring Coverage	✅ Passed	Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing touches

• 📝 Generate docstrings

---

---

📜 Recent review details

Configuration used: defaults

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 004530a and eb3bb4a.

📒 Files selected for processing (1)

• common/version/version.go

🔇 Additional comments (1)

common/version/version.go (1)

8-8: LGTM!

The patch version increment from v4.7.10 to v4.7.11 is appropriate for this bug fix release addressing the Postgres bulk insert limitation.

_{✏️ Tip: You can disable this entire section by setting review_details to false in your review settings.}

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[codecov-commenter]

Codecov Report

❌ Patch coverage is 66.66667% with 1 line in your changes missing coverage. Please review.
✅ Project coverage is 36.37%. Comparing base (7de388e) to head (004530a).

Files with missing lines	Patch %	Lines
bridge-history-api/internal/logic/history_logic.go	0.00%	1 Missing ⚠️

Additional details and impacted files

@@             Coverage Diff             @@
##           develop    #1780      +/-   ##
===========================================
- Coverage    36.39%   36.37%   -0.03%     
===========================================
  Files          248      248              
  Lines        21328    21329       +1     
===========================================
- Hits          7763     7759       -4     
- Misses       12741    12746       +5     
  Partials       824      824              

Flag	Coverage Δ
bridge-history-api	8.07% <0.00%> (ø)
common	29.45% <100.00%> (+0.05%)	⬆️
coordinator	32.15% <ø> (-0.13%)	⬇️
database	42.05% <ø> (ø)
rollup	35.08% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[coderabbitai]

Actionable comments posted: 0

🧹 Nitpick comments (1)

bridge-history-api/internal/logic/history_logic.go (1)

374-376: Logic change is correct, but consider returning the actual total.

Returning isHit=true for out-of-range pages is correct—when cached data exists but the requested page exceeds it, we know the answer without a DB fetch.

However, returning 0 for total instead of uint64(total) means callers will report 0 items exist rather than the actual count. Compare with line 402 which returns uint64(total). Clients may need the real total for pagination UI even when requesting an out-of-range page.

Consider returning actual total for consistency

 	if start >= total {
-		return nil, 0, true, nil
+		return nil, uint64(total), true, nil
 	}

Also, this change appears unrelated to the PR's stated objective of fixing Postgres bulk insert issues. Please confirm if this is intentional.

📜 Review details

Configuration used: defaults

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 7de388e and 004530a.

📒 Files selected for processing (2)

• bridge-history-api/internal/logic/history_logic.go
• common/database/db.go

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (9)

• GitHub Check: tests
• GitHub Check: check
• GitHub Check: tests
• GitHub Check: tests
• GitHub Check: tests
• GitHub Check: check
• GitHub Check: tests
• GitHub Check: check
• GitHub Check: test

🔇 Additional comments (1)

common/database/db.go (1)

53-55: LGTM! Correctly addresses the Postgres 65,535 parameter limit.

The CreateBatchSize: 1000 configuration will ensure GORM automatically splits large bulk inserts, preventing failures when inserting many records. With typical table schemas, 1000 records stays safely under the 65,535 parameter limit.