Skip to content

Conversation

@NikolayS
Copy link
Contributor

@NikolayS NikolayS commented Dec 10, 2025

Note

Introduces a standalone rds-refresh tool that clones RDS/Aurora from snapshots, updates DBLab source, triggers full refresh, and cleans up—plus Docker/CLI, configs, and docs.

  • New component: rds-refresh
    • CLI tool to orchestrate DBLab full refresh via temporary RDS/Aurora clones from snapshots (main.go, refresher.go).
    • DBLab API client to update source config and trigger/monitor refresh (dblab.go).
    • AWS RDS client for snapshot discovery, clone create/wait/delete for RDS and Aurora (rds.go).
    • Config loader with env expansion, validation, and defaults; example configs (config.go, config.example.yaml).
    • Packaging and tooling: Dockerfile, Makefile, module files (go.mod, go.sum).
    • Documentation with usage, scheduling, IAM, and networking (README.md).
  • Engine
    • Add example config: engine/configs/rds-refresh.example.yaml.
    • Update engine/go.mod/go.sum with AWS SDK (v2) indirect dependencies.

Written by Cursor Bugbot for commit 0104395. Configure here.

Add a new component that automates DBLab full refresh using temporary
RDS/Aurora database clones created from snapshots. This enables a
hassle-free data sync workflow that doesn't impact production.

Features:
- Create temporary RDS/Aurora clones from latest automated snapshots
- Wait for clone availability with proper timeout handling
- Trigger DBLab full refresh via API
- Poll refresh status until completion
- Clean up temporary clones automatically

Deployment options:
- AWS Lambda with SAM template and EventBridge scheduling
- Standalone CLI binary for cron/manual execution
- Docker container for containerized environments

Includes comprehensive documentation with IAM policy examples
and example configuration files.
Add a fully standalone version of the RDS/Aurora refresh tool that can
be built and deployed immediately without requiring a DBLab Engine
release. This version has no dependencies on DBLab internal packages.

The standalone component includes:
- Self-contained Go module with minimal dependencies
- Makefile for easy building (CLI, Lambda, Docker)
- SAM template for AWS Lambda deployment
- Dockerfile for container builds
- Comprehensive documentation

Can be used immediately by:
1. go build -o rds-refresh .
2. ./rds-refresh -config config.yaml
- Add UpdateSourceConfig method to update DBLab source connection
  before triggering refresh, ensuring DBLab knows the clone endpoint
- Add source database credentials (dbName, username, password) to
  config for DBLab connection configuration
- Remove Lambda-specific code, focusing on container/CLI deployment
  which better suits the long-running nature of refresh operations
- Remove duplicate engine-integrated code (engine/internal/rdsrefresh
  and engine/cmd/rds-refresh) since standalone component is preferred
- Update documentation with container deployment options (Docker,
  ECS Task, Kubernetes CronJob, CLI with cron)
- Update workflow to include config update step before refresh trigger
DBLab expects a flat JSON structure matching ConfigProjection fields,
not a nested structure. The API automatically reloads the config after
update (calls reloadFn internally), so no SIGHUP is needed.

Changed from nested:
  {"retrieval": {"dbSource": {"host": "..."}}}

To flat projection format:
  {"host": "...", "port": 5432, "dbname": "...", ...}
@NikolayS
Copy link
Contributor Author

@cursor review

@NikolayS NikolayS changed the title RDS/Aurora logical refresh component DOT NOT MERGE -- RDS/Aurora logical refresh component Dec 12, 2025
Copy link

@cursor cursor bot left a comment

Choose a reason for hiding this comment

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

This PR is being reviewed by Cursor Bugbot

Details

You are on the Bugbot Free tier. On this plan, Bugbot will review limited PRs each billing cycle.

To receive Bugbot reviews on all of your PRs, visit the Cursor dashboard to activate Pro and start your 14-day free trial.

The function could return success prematurely if DBLab's status still
showed StatusFinished from a previous refresh. Since /full-refresh
triggers the operation in a goroutine, polling immediately after could
see stale status.

Now tracks whether refresh has actually started before accepting
StatusFinished as success. This prevents premature clone deletion.
@NikolayS
Copy link
Contributor Author

@cursor review again

@cursor
Copy link

cursor bot commented Dec 13, 2025

Cursor Agent can help with this pull request. Just @cursor in comments and I'll start working on changes in this branch.
Learn more about Cursor Agents

…tates

- Add immediate status check before ticker loop in WaitForRefreshComplete
  to avoid unnecessary delay of up to pollInterval (30s) on first check
- Align IsRefreshInProgress with WaitForRefreshComplete by including
  StatusPending and StatusRenewed as in-progress states, preventing
  potential duplicate refresh triggers
@NikolayS
Copy link
Contributor Author

@cursor check it again

@cursor
Copy link

cursor bot commented Dec 13, 2025

I've reviewed the rds-refresh component again. All previously identified bugs have been fixed:

Review summary

✅ Bug 1: Race condition (premature completion on stale status) - FIXED

The WaitForRefreshComplete function properly uses the refreshStarted flag to prevent returning success on stale StatusFinished status.

✅ Bug 2: Inconsistent refresh status check - FIXED

The IsRefreshInProgress function now includes all active states, matching WaitForRefreshComplete:

// IsRefreshInProgress checks if a refresh is currently in progress.
// Considers all active states: refreshing, snapshotting, pending, renewed.
func (c *DBLabClient) IsRefreshInProgress(ctx context.Context) (bool, error) {
	status, err := c.GetStatus(ctx)
	if err != nil {
		return false, err
	}

	switch status.Retrieving.Status {
	case StatusRefreshing, StatusSnapshotting, StatusPending, StatusRenewed:
		return true, nil
	default:
		return false, nil
	}
}

✅ Bug 3: Delayed first status check - FIXED

The WaitForRefreshComplete now performs an immediate status check before starting the polling loop:

	// immediate first check
	if done, err := checkStatus(); err != nil {
		return err
	} else if done {
		return nil
	}

	ticker := time.NewTicker(pollInterval)

No further issues found. The code looks ready for review from a correctness standpoint.


Open in Cursor Open in Web

Learn more about Cursor Agents

@NikolayS
Copy link
Contributor Author

@agneum could you please have a look at this (of course, we need to bring this to gitlab and test thoroughly)

- Add problem/solution section with ASCII diagram
- Add prerequisites section
- Restructure quick start with numbered steps
- Add configuration reference table
- Simplify scheduling examples (Docker cron, K8s, ECS)
- Add network requirements diagram
- Add cost estimates
- Improve troubleshooting section
@NikolayS
Copy link
Contributor Author

@cursor review the instructions in README, and scrutinize it -- any potential issues?

Copy link

@cursor cursor bot left a comment

Choose a reason for hiding this comment

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

✅ Bugbot reviewed your changes and found no bugs!


Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

3 participants