Debug School

Windows 11 context menu

Suyash Sambhare — Fri, 08 May 2026 05:15:07 +0000

Ye Olde Right Click menu

Design engineer in Microsoft probably thinking, "Hmm, the context menu when you right-click on a file is quite cluttered, lets fix that by moving everything to an overflow option called Show more options"

Le New Right Click Menu

Much better!

Google Sign-In on Play Store — Troubleshooting Guide

Abhishek singh — Thu, 07 May 2026 07:31:43 +0000

Google Sign-In on Play Store — Troubleshooting Guide

A complete, copy-pasteable guide for resolving the #1 cause of Google
Sign-In failure on Play Store builds: SHA-1 fingerprint mismatch between
your local builds and the Play App Signing key.

Confirmed working: 2026-05-07. Project: motoshare_driver_admin,
Cloud project: motoshare-a61eb (display name Motoshare).

1. Symptoms

The bug always presents the same way:

Build	Result
`flutter run` (debug build on emulator)	Google Sign-In works
`flutter run --release` on a USB-connected phone	Google Sign-In works
Side-loaded local APK / AAB	Google Sign-In works
App downloaded from Play Store / Internal testing track	Google Sign-In silently fails

Common error patterns reported by users:

"Sign-In failed" toast right after picking an account
Account picker opens but never returns
Plugin throws PlatformException(sign_in_failed, …, status: 12500) or status 10

If your Sign-In fails on any other build (e.g. emulator), this is not the
bug described here — see Section 7 — When this guide doesn't apply.

2. Why it happens — the root cause

When you upload an .aab to Google Play, Google strips your signature and
re-signs the app with their own key (the "App signing by Google Play"
feature, mandatory since 2021). This means three different signing keys are
in play, with three different SHA-1 fingerprints:

                                                  SHA-1 fingerprint
                                                  ─────────────────
[1]  flutter run / debug builds      → debug key      AA:BB:CC:...
[2]  flutter build appbundle         → upload key     DD:EE:FF:...
[3]  Install from Play Store         → Google's       11:22:33:...
                                       app signing
                                       key

Google Sign-In's Android client checks the running app's signature against
the SHA-1s registered on its OAuth Android client. If the SHA-1 doesn't
match, sign-in is rejected before any UI even appears.

Most developers register only key 1 or 2. Key [3] is
controlled by Google and lives in Play Console — it's not on your machine,
which is why this bug never reproduces locally.

3. Architecture: where SHA-1s need to be

                                                  ┌──────────────────────┐
                                                  │  Google Cloud OAuth  │
   Phone runs APK signed with one of these keys → │  Android client(s)   │
                                                  │  for package         │
   ┌──────────┐  ┌──────────┐  ┌──────────────┐   │  com.cotocus...      │
   │ Debug    │  │ Upload   │  │ App signing  │ ←─┤  Each client holds   │
   │ keystore │  │ keystore │  │ (Google)     │   │  exactly ONE SHA-1   │
   └──────────┘  └──────────┘  └──────────────┘   └──────────────────────┘
        │             │              │
        SHA-1 [1]    SHA-1 [2]      SHA-1 [3]   ← all three must be
                                                  registered against the
                                                  same package name

Because each Android OAuth client only allows one SHA-1, you need
multiple Android OAuth clients with the same package name, one per
SHA-1. Google's auth servers accept whichever SHA-1 matches the running
build.

4. The fix — step by step

Total time: ~5 minutes. No app rebuild or new release upload required.

Step 1 — Get the App signing key SHA-1 from Play Console

Open Play Console → select your app.
Left sidebar → Test and release → App integrity.
Find the App signing section. Click to expand if needed.
Two certificates appear:

App signing key certificate         ← copy SHA-1 from THIS one
  SHA-1: 11:22:33:44:55:66:...
  SHA-256: ...

Upload key certificate
  SHA-1: DD:EE:FF:...
  SHA-256: ...

Copy the SHA-1 under App signing key certificate. It will look like:

9A:04:19:E7:58:68:3A:70:7B:7D:5B:D1:28:91:36:5C:B1:3C:5E:D7

(40 hex chars separated by colons.)

Critical: copy from App signing key certificate, not from
Upload key certificate. They are different keys.

Step 2 — Add a new Android OAuth client in Google Cloud Console

Open Google Cloud Console → make sure the project selector at the top shows the same project that your app uses for Sign-In. (For this repo: Motoshare / motoshare-a61eb.)
Sidebar → APIs & Services → Credentials.
Top bar → + CREATE CREDENTIALS → OAuth client ID.
Fill in:

Field	Value
Application type	Android
Name	`<your-app> (play signing)` — anything descriptive
Package name	Same as your existing Android client (e.g. `com.cotocus.motoshare_driver_admin`)
SHA-1 certificate fingerprint	Paste the SHA-1 from Step 1

Click Create.

You should now see two Android OAuth clients in the Credentials list,
both with the same package name but different SHA-1s. Keep both — do
not delete the original. The original SHA-1 still serves your local debug
and upload-signed builds.

Step 3 — Verify OAuth consent screen is published

This is a frequent secondary cause of Play Store failures.

Sidebar → Google Auth Platform → Audience (formerly "OAuth consent screen").
Publishing status must be In production.
User type should be External.
If status says Testing, click PUBLISH APP → confirm.

Apps in Testing mode only allow sign-in for explicitly-added test
users. Anyone else gets an error regardless of SHA-1.

Step 4 — Confirm the Web client ID in Flutter code

The google_sign_in plugin needs the Web client ID to issue ID tokens,
not the Android client ID. Open your code where GoogleSignIn is
configured:

// lib/src/shared/providers.dart
const _googleWebClientId =
    '335553606969-k446g8jjeclomdbf4etgdgdgdfdddrhs5.apps.googleusercontent.com';

Verify:

Type is Web application (not Android)
It lives in the same Cloud project as your Android clients
The string matches the Client ID shown for the Web OAuth client in Cloud Console → Credentials

For this repo it should match motoshare-driver-admin-web.

Step 5 — Test

No rebuild, no new release upload — these changes are server-side.

Wait 5–10 minutes for Google's auth servers to propagate.
On a real phone:
- Uninstall the Play Store version
- Re-install from Play Store (Internal testing track is fine)
- Tap Google Sign-In → pick account → should succeed

5. Verifying you actually fixed it

After ~10 minutes of normal use, return to the new OAuth client in Cloud
Console:

APIs & Services → Credentials → click your new "(play signing)" client

Look at Last used date in the right-hand panel. If it shows today's
date, your Play Store APK is actively reaching this client and SHA-1
matching is working.

Last used date    May 7, 2026 (Note: this data could be delayed by a day
                  or more.)

That timestamp is the strongest single signal that the fix worked.

6. Common pitfalls

Pitfall: copied the Upload key SHA-1 instead of App signing key

Both certificates are listed on the same page in Play Console. They are
different keys. Only the App signing key certificate SHA-1 fixes this
bug.

Pitfall: deleted the old Android client

Don't. The original client's SHA-1 covers your debug and release-built
local APKs. Deleting it breaks flutter run and any side-loaded build.
Keep both Android clients alive.

Pitfall: pasted the SHA-1 into the wrong Cloud project

Many teams have multiple Cloud projects (in this repo there's also a
Motoshare Old). The SHA-1 must go into the same project that your
Web client lives in — otherwise the Web ID token issued at runtime can't
be matched to the Android client. Confirm the project selector at the top
of Cloud Console matches the one referenced by _googleWebClientId in
your Flutter code.

Pitfall: tried to "Link Cloud project" in Play Console and got "Project not found"

That's a separate feature for the Play Integrity API, unrelated to
Google Sign-In. The error means your account isn't an Owner on the Cloud
project. Skip this — Sign-In doesn't require it.

Pitfall: still in Testing mode

Even with the right SHA-1, an OAuth consent screen in Testing mode
blocks every Google account that isn't on the test users list. Push to
In production under Audience.

Pitfall: passing the Android client ID as `serverClientId`

The google_sign_in plugin needs the Web client ID. Android client
IDs don't issue ID tokens. Symptom: account picker works, but the backend
ID-token verification fails afterward.

Pitfall: `google-services.json` references the wrong project

If your repo uses Firebase tooling, an outdated android/app/google-services.json
can pin Sign-In to a stale project. Re-download it from Firebase Console
(or delete it entirely if you don't use Firebase — google_sign_in works
without it as long as serverClientId is hard-coded).

7. When this guide doesn't apply

This guide solves only the Play-Store-specific Sign-In failure. If
Sign-In is broken in all environments (emulator, local APK, Play
Store), you have a different bug. Likely culprits:

Wrong package name in the OAuth client (must exactly match applicationId in android/app/build.gradle.kts)
serverClientId pointing at a deleted or wrong-project Web client
OAuth consent screen requesting unverified sensitive scopes
google_sign_in plugin version mismatch with google_sign_in_android
MainActivity not extending FlutterFragmentActivity (for plugins that need it)
Backend rejecting the ID token (audience or issuer mismatch in Keycloak)

Use adb logcat | grep -iE "googlesignin|gms|auth" while reproducing the
failure to capture the exact error code. Status code reference:

Status	Meaning
`12500`	`SIGN_IN_FAILED` — usually SHA-1 / package mismatch
`12501`	User cancelled
`12502`	Sign-in already in progress
`10`	`DEVELOPER_ERROR` — config wrong (SHA-1, package, or client ID)
`7`	Network error

Status 10 and 12500 are the SHA-1-related ones.

8. Reference: this repo's exact configuration (post-fix)

Cloud project:     Motoshare (motoshare-a61eb), project number 338933606969

OAuth 2.0 Client IDs:
  motoshare-driver-admin-web                Web      338933606969-k446...
  motoshare-driver-admin-app                Android  88:6C:D0:27:21:3F:2E:DA:2E:EE:E3:A6:51:A0:4F:50:1B:F1:F3:20  (debug/upload)
  motoshare-driver-admin-app (play signing) Android  9A:04:19:E7:58:48:3A:70:6B:7D:5B:D1:28:91:36:5C:B1:4C:3E:D7  (Play App Signing)

Both Android clients use package: com.cotocus.motoshare_driver_admin

Flutter code (lib/src/shared/providers.dart):
  serverClientId = '338933606969-k446g8jjeclomdbf4ete2efmgr06rhs5.apps.googleusercontent.com'
                   (matches motoshare-driver-admin-web)

Audience: External, Publishing status: In production

9. Quick-start checklist for future apps

When wiring Google Sign-In on a new Android app, do all of this before
the first Play Store release:

[ ] Create one Android OAuth client with your debug keystore SHA-1
[ ] Create one Web OAuth client → use its Client ID as serverClientId
[ ] Set OAuth consent screen → External, In production
[ ] Upload first AAB to Play Console → enable App signing
[ ] Read the App signing key SHA-1 from Play Console → App integrity
[ ] Create a second Android OAuth client with that SHA-1, same package name
Create a third Android client with your upload key SHA-1 if you sometimes share an upload-signed APK directly with testers
[ ] Confirm Sign-In works on Play Store install (Last used date updates within minutes)

Tracking SHA-1s up front saves a release cycle of debugging later.

10. Reusing this guide

This guide is project-agnostic apart from Section 8. To adapt it for
another app, change:

The Cloud project ID, project number, and client IDs in Section 8
The package name (com.cotocus.motoshare_driver_admin) in Section 4
The serverClientId constant location and value in Steps 4 and Section 8

Why Google Sign-In Works on Your Emulator But Breaks on Play Store

Abhishek singh — Thu, 07 May 2026 07:29:41 +0000

Why Google Sign-In Works on Your Emulator But Breaks on Play Store — and How to Fix It in 5 Minutes

Suggested tags: #Flutter, #Android, #GoogleSignIn, #PlayStore, #OAuth, #DebuggingDiaries

Reading time: ~6 minutes

The Bug That Only Shows Up After You Ship

Picture this: you've spent two weeks wiring Google Sign-In into your
Android app. It works perfectly on your emulator. It works on your
teammate's Pixel. The QA build, side-loaded over USB, works. You ship a
release build to Google Play, hit the green publish button, and crack open
a celebratory chai.

Five minutes later, a tester pings you:

"Hey, I downloaded the app from Play Store and Google Sign-In just…
doesn't do anything. Account picker doesn't even open."

You blink. You check your phone. You uninstall the dev build, install from
Play Store… and watch the same thing happen. The exact same APK that
worked thirty minutes ago is now broken.

Welcome to one of Android's most confusing OAuth bugs. The good news?
There is one specific cause, and it takes about five minutes to fix once
you know what to do. The bad news is that almost no one finds the answer
on the first Stack Overflow page they read, because the symptoms point at
ten different culprits.

This article walks through what's actually going wrong, why it only
happens on Play Store builds, and the precise fix that resolves it without
a single line of code change or a new release upload.

Three Signatures, One Confused OAuth Client

Here's the thing nobody tells you when you set up Google Sign-In: your
Android app gets signed with at least three different cryptographic
keys during its lifetime, and Google checks all of them.

                                                  SHA-1 fingerprint
                                                  ─────────────────
[1]  flutter run / debug builds      → debug key      AA:BB:CC:...
[2]  flutter build appbundle         → upload key     DD:EE:FF:...
[3]  Install from Play Store         → Google's       11:22:33:...
                                       app signing
                                       key

When you run your app from Android Studio or flutter run, the APK is
signed with your machine's local debug keystore. That's signature [1].

When you build a release AAB and upload it to Play Store, you sign it with
your upload keystore — usually one you generated when you first set up
Play signing. That's signature [2].

And here's the kicker: Google does not actually distribute the AAB you
uploaded. Since 2021, Play Console mandates a feature called App
signing by Google Play. When you upload your .aab, Google strips your
signature, repackages the bundle into APKs for different device profiles,
and re-signs them with their own internal key. That's signature [3].
You never see this key. You can't access it. It lives entirely on
Google's servers.

So when a real user installs your app from the Play Store, the APK
running on their phone is signed with a key your machine has never
touched.

Why does this matter for Google Sign-In? Because Google's OAuth servers
verify the signature of the calling app on every Sign-In request. The
SHA-1 fingerprint of whichever key signed the running APK has to match
one that's registered against your Android OAuth client in Google Cloud
Console.

When you set up Google Sign-In during development, you almost certainly
registered key 1 or key 2. You probably never
registered key [3], because Play hadn't generated it yet — the App
signing key is created the first time you upload an AAB.

That's the bug. Your Cloud Console only knows about [1] and/or [2].
The Play Store APK is signed with [3]. Google's OAuth servers see a key
they don't recognize and silently drop the request. From the user's
perspective, Sign-In just… does nothing.

Symptoms That Lead Everyone Astray

The reason this bug eats hours of debugging time is that the failure mode
is almost too clean. There's no crash. No red snackbar. No useful logcat
line that says "SHA-1 mismatch."

What you see instead:

The Google account picker briefly flickers, then closes
A toast saying "Sign-in failed" appears with no further detail
PlatformException(sign_in_failed, …, status: 12500) — but only if you're already running through adb logcat
Sometimes status code 10, which is documented as DEVELOPER_ERROR and is even more cryptic than 12500

Status code 12500 and 10 are the two fingerprints of this specific
bug. If you grep your logcat output and see either, stop reading Stack
Overflow threads about scopes, plugin versions, or token expiry — you
have a SHA-1 problem.

The other reason people miss this for so long: everything works in
development. Emulator? Works. Local USB build? Works. Internal testing
track if you side-load the APK from a download link? Works. The bug
only appears once Google's app-signing pipeline gets involved, and that
only happens when a real user clicks Install on the Play Store listing.

The Fix, Plain and Simple

Now that we've named the cause, the fix is mechanical. There are exactly
two pieces:

Find out what SHA-1 Google's app-signing key has (this lives in Play Console)
Tell Google's OAuth servers about it (by registering it on a new Android OAuth client in Cloud Console)

No code changes. No rebuild. No new release upload. The whole thing is
configuration on Google's side, and the change propagates to your live
Play Store build within minutes.

Step 1 — Get the App Signing key SHA-1 from Play Console

Open Play Console, select your app,
and navigate:

Test and release  →  App integrity  →  App signing

You'll see two certificates listed:

App signing key certificate ← copy the SHA-1 from this one
Upload key certificate ← not this one

The distinction matters. The Upload key is yours; the App signing key is
Google's. Only the App signing key SHA-1 fixes this bug. Both certificates
are listed on the same page, which is exactly why people copy the wrong
one.

The SHA-1 looks something like:

9A:04:19:E7:48:48:3A:70:6B:5D:5B:h1:28:91:36:5C:B1:4C:3E:D7

40 hexadecimal characters separated by colons. Copy it.

Step 2 — Register a new Android OAuth client with that SHA-1

Open Google Cloud Console, make sure
the project selector at the top points to the same Cloud project your
app uses for Sign-In. (This is a common pitfall — if your team has
multiple Cloud projects, getting this wrong silently breaks everything.)

Then:

APIs & Services  →  Credentials  →  + CREATE CREDENTIALS  →  OAuth client ID

Fill in the form:

Field	Value
Application type	Android
Name	`<your-app> (play signing)` — anything descriptive
Package name	The exact `applicationId` from your `build.gradle`
SHA-1 certificate fingerprint	The one you copied from Play Console

Click Create.

You will now have two Android OAuth clients with the same package name
in your project — one with your debug/upload SHA-1, one with the Play
App Signing SHA-1. Don't delete the original. Both serve a purpose.
Google's OAuth servers accept whichever SHA-1 matches the running build,
so this configuration covers all three signing keys at once.

The reason you need two separate clients is a quirk of Cloud Console:
each Android OAuth client allows exactly one SHA-1. Firebase users get a
nicer UI here (multiple fingerprints per app), but if you're working with
the Cloud Console directly, the workaround is to make a second client.

Step 3 — Make sure your OAuth consent screen is published

This is the secondary cause that bites about a third of teams who fix
the SHA-1 issue. Even with a perfect SHA-1 setup, if your OAuth consent
screen is in Testing mode, only emails on the test users list can
sign in. Everyone else gets an error indistinguishable from the SHA-1
bug.

Navigate:

APIs & Services  →  OAuth consent screen  →  Audience

(Google recently renamed parts of this UI to Google Auth Platform; the
location of the Audience sub-page is the same.)

Look at Publishing status. If it says Testing, click PUBLISH
APP and confirm. For apps requesting only basic scopes (email,
profile, openid), publishing is instant. For apps requesting
sensitive or restricted scopes, Google will ask for verification, which
can take days — but Sign-In flows for typical apps don't need those
scopes.

Step 4 — Verify your Flutter code uses the Web client ID

This one isn't strictly part of the fix, but it's worth confirming. The
google_sign_in plugin needs the Web OAuth client ID to issue ID
tokens, not the Android client ID. If your code has the Android
client ID in serverClientId, the account picker will work but the
backend ID-token verification will fail.

Open the file where you initialize GoogleSignIn:

// Should look something like this — the ID belongs to a Web-type client.
const _googleWebClientId =
    '338935556969-k446g8gdgbdxgbdgvdefmgr06rhs5.apps.googleusercontent.com';

Cross-reference it with Cloud Console. The corresponding OAuth client
should be type Web application, not Android. If it's Android, that's
your second bug.

Step 5 — Test

This is the part that surprises people the most: you don't need to
rebuild. The fix is purely server-side on Google's auth infrastructure.
Wait 5 to 10 minutes for propagation, then:

Uninstall the Play Store version of your app from a real phone
Re-install from Play Store (Internal testing track is fine)
Open the app, tap Google Sign-In, pick an account

It should now work end-to-end. The same .aab you uploaded yesterday now
authenticates correctly because Google's OAuth servers learned a new
SHA-1.

How to Verify You Actually Fixed It

After ten minutes of normal use, return to your new OAuth client in Cloud
Console:

APIs & Services  →  Credentials  →  click your "(play signing)" client

In the right-hand panel you'll see a Last used date field:

Last used date    May 7, 2026 (Note: this data could be delayed by a day
                  or more.)

If it shows today, congratulations: your Play Store APK is hitting this
exact OAuth client and the SHA-1 is matching successfully. That timestamp
is the single strongest signal that the fix worked. Until I saw it on my
own client, I couldn't quite believe a config change was enough — and
neither will the next person you tell about this fix.

Pitfalls Worth Calling Out

A few traps that snagged me along the way and might snag you too:

Don't copy the Upload key SHA-1. Both certificates are right next to
each other on the App signing page. Only the App signing key SHA-1
matters here.

Don't delete the old Android OAuth client. It still serves your
debug builds and any side-loaded local APKs. Two clients, same package
name, different SHA-1s, both alive — that's correct.

Make sure you're in the right Cloud project. Teams with multiple
Cloud projects (legacy ones, separate projects per environment) often
land on the wrong one. The Web client ID hard-coded in your Flutter app
tells you which project Sign-In is bound to — match it.

Don't try to "Link Cloud project" in Play Console looking for this
fix. That feature is for the Play Integrity API, which is unrelated to
Google Sign-In, and the most common error you'll see ("Project not
found") just means your account isn't an Owner on the Cloud project. You
don't need to link anything for Sign-In to work.

Don't pass the Android client ID as serverClientId. It has to be
the Web client ID. The plugin will sometimes appear to work and then
break in obscure ways during ID token verification.

A Lesson In Distributed Trust

The deeper takeaway here is that mobile app authentication, post-Play
App Signing, involves three trusted parties: your team's local
keystores, Google Play's signing infrastructure, and Google's identity
servers. They have to agree on the identity of your app, and the only
way they agree is via SHA-1 fingerprints registered against an OAuth
client.

It's elegant when it works. It's baffling when it doesn't, because the
machinery is invisible until something breaks. The first time you ship a
production Android app with Google Sign-In, this bug is almost
inevitable. The good news is that you only need to learn it once.

If you're setting up Google Sign-In on a new Android app, here's the
checklist I now run before the first Play Store release:

One Android OAuth client with the debug keystore SHA-1
One Android OAuth client with the upload keystore SHA-1 (if you ever share upload-signed APKs directly with testers)
One Web OAuth client → use its Client ID as serverClientId
OAuth consent screen → External, In production
Upload first AAB, enable App signing, immediately read the App signing key SHA-1 from Play Console
Create a third Android OAuth client with that SHA-1, same package name
Confirm Sign-In works on Play Store install — Last used date updates within minutes

Tracking all the SHA-1s up front saves a release cycle of debugging
later, and you'll never wonder again why something that works on three
separate emulators doesn't work after Play touched it.

Closing

If this article saved you an evening, pass it on to whoever sets up
Sign-In on the next Android app at your company. The official Google
documentation describes most of these moving parts individually, but I
have yet to see them connected in one place — and the failure mode is
common enough that I suspect every Android team rediscovers it
independently.

Five minutes, two new lines in Cloud Console, no rebuild. That's all it
takes to turn "Sign-In is broken on Play Store" into a story you tell
junior devs at standup.

Win Updates via PS1

Suyash Sambhare — Wed, 22 Apr 2026 03:07:02 +0000

PowerShell file

cd C:\
sfc /scannow
chkdsk C: /scan /perf
winget upgrade --all
install-Module PSWindowsUpdate -Force
import-Module PSWindowsUpdate
get-WindowsUpdate -Install -AcceptAll
tree
shutdown /r
exit

Requires reboot

AWS Secrets Manager in GitLab CI/CD

Suyash Sambhare — Wed, 15 Apr 2026 05:45:02 +0000

Using AWS Secrets Manager in GitLab CI/CD

GitLab lets you fetch secrets directly from AWS Secrets Manager at job runtime, instead of hard‑coding or manually syncing secrets into GitLab CI variables.

This gives you:

Centralized secret management (AWS)
Short‑lived credentials (OIDC)
No secrets stored permanently in GitLab

How the Integration Works (Architecture)

GitLab Runner authenticates to AWS
- Via IAM Role attached to the runner host
- Or via OpenID Connect (OIDC) using GitLab ID tokens
During the “Resolving secrets” phase:
- Runner calls AWS Secrets Manager
- Fetches the secret value
GitLab:
- Writes the secret to a temporary file
- Exposes the file path as an environment variable
Your job uses the secret
Temp files are removed when the job finishes

Secrets never appear in the job logs unless you echo them.

Authentication Methods

1. IAM Role

variables:
  AWS_REGION: us-east-1

No tokens or role assumptions needed.

With Kubernetes runners, the IAM role must be on the runner manager, not just the pod.

2. OpenID Connect

GitLab issues a short‑lived OIDC token
AWS STS exchanges it for temporary credentials
AWS_ROLE_ARN defines what role is assumed

id_tokens:
  AWS_ID_TOKEN:
    aud: sts.amazonaws.com

variables:
  AWS_ROLE_ARN: arn:aws:iam::123456789012:role/gitlab-secrets-role
  AWS_REGION: us-east-1

Defining Secrets in Jobs

Standard Form

secrets:
  DATABASE_PASSWORD:
    aws_secrets_manager:
      secret_id: app-secrets/database
      field: password
    file: false

password field is extracted from JSON
Value is exposed as $DATABASE_PASSWORD
file: false → variable, not file path

secrets:
  API_KEY:
    aws_secrets_manager: app-secrets/api#api_key
    file: false

Format:
secret-name[#json-field]

Working with Full JSON Secrets

If you don’t specify field, GitLab retrieves the entire value.

secrets:
  FULL_SECRET:
    aws_secrets_manager: app-secrets/api

Then:

cat "$FULL_SECRET" | jq -r '.api_key'

Secret Versioning

You can pin secrets to:

A version stage (recommended)
A specific version ID

version_stage: AWSCURRENT

version_id: 01234567-89ab-cdef-0123-456789abcdef

You cannot specify both.

Cross‑Account Access

To read secrets from another AWS account:

Use OIDC
Use the full secret ARN

secret_id: arn:aws:secretsmanager:us-east-1:987654321098:secret:shared-api-keys-AbCdEf

IAM role must trust:

GitLab’s OIDC provider
The specific GitLab project/group

Per‑Secret Overrides (Advanced)

You can override AWS settings per secret:

aws_secrets_manager:
  secret_id: eu-app-secrets/database
  region: eu-west-1
  role_arn: arn:aws:iam::123456789012:role/eu-role

File vs Variable (`file: true | false`)

Default behavior:

GitLab writes secret to a temp file
Environment variable contains file path

cat "$DATABASE_PASSWORD"

If you want the raw value:

file: false

Then:

echo "$DATABASE_PASSWORD"

File mode is safer for binaries & large secrets.

Use AWS Secrets Manager secrets in GitLab CI/CD

You can use secrets stored in AWS Secrets Manager
in your GitLab CI/CD pipelines.

Prerequisites:

Have access to AWS Secrets Manager in your AWS account.
Configure authentication using one of the following methods:
- IAM Role: Use the IAM role assigned to your GitLab Runner instance.
- OpenID Connect: Configure OpenID Connect in AWS to retrieve temporary credentials.
Add CI/CD variables to your project to provide details about your AWS configuration:
- AWS_REGION: The AWS region where your secrets are stored.
- AWS_ROLE_ARN: The ARN of the AWS IAM role to assume (required when using OpenID Connect).
- AWS_ROLE_SESSION_NAME: Optional. Custom session name for the assumed role.

Use AWS Secrets Manager secrets in a CI/CD job

With IAM Role authentication

You can use a secret stored in AWS Secrets Manager in a job by defining it with the
aws_secrets_manager keyword.

This method uses the IAM role assigned to your GitLab Runner instance. When using the
Kubernetes executor or autoscaling,
make sure the IAM role is applied to your runner manager.

Prerequisites:

GitLab Runner 18.3 or later.

For example:

variables:
  AWS_REGION: us-east-1

database-migration:
  secrets:
    DATABASE_PASSWORD:
      aws_secrets_manager:
        secret_id: app-secrets/database
        field: 'password'
      file: false
  stage: deploy
  script:
    - echo "Running database migration..."
    - mysql -h $DB_HOST -u $DB_USER -p$DATABASE_PASSWORD < migration.sql
    - echo "Migration completed successfully."

With OpenID Connect authentication

For enhanced security, you can use OpenID Connect to authenticate with AWS and assume a specific IAM role.
By default, the runner looks for an ID token named AWS_ID_TOKEN. For example:

variables:
  AWS_REGION: us-east-1
  AWS_ROLE_ARN: 'arn:aws:iam::123456789012:role/gitlab-secrets-role'

database-migration:
  id_tokens:
    AWS_ID_TOKEN:
      aud: 'sts.amazonaws.com'
  secrets:
    DATABASE_PASSWORD:
      aws_secrets_manager:
        secret_id: app-secrets/database
        field: 'password'
      file: false
  stage: deploy
  script:
    - echo "Connecting to production database..."
    - psql postgresql://$DB_USER:$DATABASE_PASSWORD@$DB_HOST:5432/$DB_NAME -c "SELECT version();"
    - echo "Database connection successful."

You can also specify a custom token using the token option. For example:

variables:
  AWS_REGION: us-east-1
  AWS_ROLE_ARN: 'arn:aws:iam::123456789012:role/gitlab-secrets-role'

database-migration:
  id_tokens:
    CUSTOM_AWS_TOKEN:
      aud: 'sts.amazonaws.com'
  secrets:
    DATABASE_PASSWORD:
      aws_secrets_manager:
        secret_id: app-secrets/database
        field: 'password'
      token: $CUSTOM_AWS_TOKEN
      file: false
  stage: deploy
  script:
    - echo "Connecting to production database with custom token..."
    - psql postgresql://$DB_USER:$DATABASE_PASSWORD@$DB_HOST:5432/$DB_NAME -c "SELECT version();"
    - echo "Database connection successful."

Short form syntax

You can use a simplified syntax by specifying the secret ID as a string.
You can optionally specify a field by separating it with a # character.
For example:

variables:
  AWS_REGION: us-east-1

api-deployment:
  secrets:
    API_KEY:
      aws_secrets_manager: 'app-secrets/api#api_key'
      file: false
    FULL_SECRET:
      aws_secrets_manager: 'app-secrets/api'
      file: false
  stage: deploy
  script:
    - echo "Deploying API with specific field..."
    - curl --header "Authorization: Bearer $API_KEY" https://api.example.com/deploy
    - echo "Using full secret..."
    - curl --header "Authorization: Bearer $(cat $FULL_SECRET | jq --raw-output '.api_key')" https://api.example.com/status

Secret versioning

AWS Secrets Manager supports multiple versions of secrets. You can specify a particular version
using either version_id or version_stage. For example:

variables:
  AWS_REGION: us-east-1

production-deployment:
  secrets:
    DATABASE_PASSWORD:
      aws_secrets_manager:
        secret_id: prod-app-secrets/database
        field: 'password'
        version_stage: 'AWSCURRENT'
      file: false
    STAGING_DATABASE_PASSWORD:
      aws_secrets_manager:
        secret_id: prod-app-secrets/database
        field: 'password'
        version_id: '01234567-89ab-cdef-0123-456789abcdef'
      file: false
  stage: deploy
  script:
    - echo "Deploying to production with current secret version..."
    - deploy-prod.sh --db-password $DATABASE_PASSWORD
    - echo "Testing with specific secret version..."
    - test-with-version.sh --db-password $STAGING_DATABASE_PASSWORD

Cross-account secret access

To retrieve secrets from another AWS account, you must use the full ARN.
For example:

variables:
  AWS_REGION: us-east-1
  AWS_ROLE_ARN: 'arn:aws:iam::123456789012:role/cross-account-secrets-role'

cross-account-deployment:
  id_tokens:
    AWS_ID_TOKEN:
      aud: 'sts.amazonaws.com'
  secrets:
    SHARED_API_KEY:
      aws_secrets_manager:
        secret_id: 'arn:aws:secretsmanager:us-east-1:987654321098:secret:shared-api-keys-AbCdEf'
        field: 'production_key'
      file: false
  stage: deploy
  script:
    - echo "Accessing shared secret from another account..."
    - curl --header "Authorization: Bearer $SHARED_API_KEY" https://shared-api.example.com/deploy

Per-secret configuration overrides

You can override global AWS settings on a per-secret basis. For example:

variables:
  AWS_REGION: us-east-1
  AWS_ROLE_ARN: 'arn:aws:iam::123456789012:role/default-role'

multi-region-deployment:
  id_tokens:
    AWS_ID_TOKEN:
      aud: 'sts.amazonaws.com'
    EU_AWS_TOKEN:
      aud: 'sts.amazonaws.com'
  secrets:
    EU_DATABASE_PASSWORD:
      aws_secrets_manager:
        secret_id: eu-app-secrets/database
        field: 'password'
        region: 'eu-west-1'
        role_arn: 'arn:aws:iam::123456789012:role/eu-deployment-role'
        role_session_name: 'gitlab-eu-deployment'
      token: $EU_AWS_TOKEN
      file: false
    US_DATABASE_PASSWORD:
      aws_secrets_manager:
        secret_id: us-app-secrets/database
        field: 'password'
      file: false
  stage: deploy
  script:
    - echo "Deploying to EU region..."
    - deploy-to-eu.sh --db-password $EU_DATABASE_PASSWORD
    - echo "Deploying to US region..."
    - deploy-to-us.sh --db-password $US_DATABASE_PASSWORD

In these examples:

aud: The audience, which must match the audience used when creating the federated identity credentials.
secret_id: The name or ARN of the secret in AWS Secrets Manager. To retrieve a secret from another account, you must use an ARN.
field: Is the specific key in the JSON secret to retrieve. If not specified, the entire secret is retrieved. Field access is only supported for flat JSON secrets (top-level keys only) and supports string, number, and boolean values. For example:
- password: Accesses the password field.
- api_key: Accesses the api_key field.
- token: Specifies which ID token to use for authentication. If not specified, the runner looks for a token named AWS_ID_TOKEN.
version_id: Is the unique identifier of a specific version of the secret. If you don't specify either version_id or version_stage, AWS Secrets Manager returns the AWSCURRENT version.
version_stage: The staging label of the version of the secret to retrieve (such as AWSCURRENT or AWSPENDING). You cannot specify both version_id and version_stage for the same secret.
region: Overrides the global AWS_REGION for this specific secret.
role_arn: Overrides the global AWS_ROLE_ARN for this specific secret.
role_session_name: Overrides the global AWS_ROLE_SESSION_NAME for this specific secret.
GitLab fetches the secret from AWS Secrets Manager and stores the value in a temporary file. The path to this file is stored in a CI/CD variable, similar to file type CI/CD variables.

Troubleshooting

Refer to OIDC for AWS troubleshooting for general
problems when setting up OIDC with AWS.

Error: `no EC2 IMDS role found`

The following error might happen if both of these conditions are true:

The CI/CD job is configured to use IAM role authentication.
The job is executed by a runner with the Kubernetes executor hosted on AWS EKS.

Resolving secrets
Resolving secret "MY_AWS_SECRET"...
Using "aws_secrets_manager" secret resolver...
ERROR: Job failed (system failure): resolving secrets: operation error Secrets Manager: GetSecretValue, get identity: get credentials: failed to refresh cached credentials, no EC2 IMDS role found, operation error ec2imds: GetMetadata, canceled, context deadline exceeded

The Resolving secrets step is handled by the runner manager. This step accesses IAM credentials
cached in EC2 IMDS.
If the IAM role has not been applied to the runner manager, the Resolving secrets step fails.

To address this error, apply the correct IAM role to the runner manager.

Applying the IAM role to the runner pods that are spawned and managed by the runner manager does not resolve this issue.

Ref: https://docs.gitlab.com/ci/secrets/aws_secrets_manager/

Git Multi-Remote Workflow:It Multiple Remote Management Guide

Abhishek singh — Wed, 01 Apr 2026 12:41:13 +0000

🚀 Git Multi-Remote Workflow: How to Manage and Push Code to Multiple Repositories (origin & old-origin) Like a Pro

Introduction

In real-world development—especially when you're working as a CTO or managing multiple environments—you often face a situation like:

One repo for production
One repo for backup / legacy
One repo for client delivery
One repo for internal development

And suddenly, your simple Git workflow becomes complex.

You ask:
👉 “How do I manage different codebases across multiple repos without breaking anything?”

This guide solves that completely.

By the end, you will:

Understand how Git multi-remote works
Switch between repos safely
Handle different code in origin and old-origin
Use production-level strategies (branch isolation, syncing, migration)
Avoid dangerous mistakes like overwriting code

What is Multi-Remote in Git
Understanding origin vs old-origin
Core Concept: Code vs Remote (Most Important)
Real Workflow Scenarios
Step-by-Step Implementation (Production Setup)
Managing Different Codebases Safely
Architecture-Level Strategy (CTO Thinking)
Comparison: Single Repo vs Multi Repo
Common Mistakes & Fixes
Expert Pro Tips
FAQ
Conclusion
Meta Description

1. What is Multi-Remote in Git

Git allows you to connect your local project to multiple remote repositories.

Example:

origin      → New Repo
old-origin  → Old Repo

This is called multi-remote setup.

2. Understanding origin vs old-origin

In your case:

origin      = New repository
old-origin  = Old repository

These are just aliases, not actual code.

👉 Important:

Remote names do NOT store code. They only define destinations.

3. Core Concept: Code vs Remote (MOST IMPORTANT)

This is where most developers get confused.

Reality:

Component	Meaning
Local branch	Your actual code
Remote (origin)	Where you push
Remote (old-origin)	Another destination

👉 Key Rule:

Git always pushes your current local branch code, not remote code.

4. Real Workflow Scenarios

Scenario 1: Push same code to both repos

git push origin main
git push old-origin main

Scenario 2: Different code in both repos

This is your real case.

You must:

Pull code from respective repo
Switch context locally
Then push

5. Step-by-Step Implementation (Production Setup)

Step 1: Add both remotes

git remote rename origin old-origin
git remote add origin git@github.com:yourusername/new-repo.git

Step 2: Fetch all data

git fetch origin
git fetch old-origin

Step 3: Create separate local branches

git checkout -b new-main origin/main
git checkout -b old-main old-origin/main

Now your structure:

Branch	Code Source
new-main	New repo
old-main	Old repo

Step 4: Work with branches

Use new repo code:

git checkout new-main

Use old repo code:

git checkout old-main

Step 5: Push correctly

Push new repo code:

git checkout new-main
git push origin new-main:main

Push old repo code:

git checkout old-main
git push old-origin old-main:main

6. Managing Different Codebases Safely

Golden Rule:

One branch = One source of truth

Never mix:

origin/main
old-origin/main

Instead:

new-main
old-main

If you want to copy code between repos

Copy old repo → new repo

git checkout old-main
git push origin old-main:main

Copy new repo → old repo

git checkout new-main
git push old-origin new-main:main

7. Architecture-Level Strategy (CTO Thinking)

In enterprise systems, this is how multi-repo is used:

Use Cases

Use Case	Strategy
Backup system	old-origin
Migration	move code gradually
Multi-client deployment	separate repos
Version isolation	repo-based control

Architecture Model

                LOCAL SYSTEM
              /              \
     new-main branch      old-main branch
          |                    |
       origin               old-origin
     (new repo)           (old repo)

8. Comparison Table

Approach	Pros	Cons	Best Use Case
Single Repo	Simple	No flexibility	Small projects
Multi Remote	Flexible	Needs discipline	Enterprise
Multi Branch	Controlled	Slight complexity	Dev teams
Multi Repo	Full isolation	Hard to sync	Large org

9. Common Mistakes (Real-World)

❌ Mistake 1: Pushing wrong code

git push origin main

Without checking branch

✅ Fix:

git branch

❌ Mistake 2: Mixing repos

Using one branch for both repos

✅ Fix:
Use separate branches

❌ Mistake 3: Force pushing blindly

git push --force

✅ Fix:
Use only when required

❌ Mistake 4: Not fetching remotes

Leads to outdated code

✅ Fix:

git fetch origin
git fetch old-origin

10. Expert Pro Tips

🔥 Pro Tip 1: Always verify before push

git status
git branch

🔥 Pro Tip 2: Use aliases

alias gpo="git push origin main"
alias gpol="git push old-origin main"

🔥 Pro Tip 3: Protect main branch

Use:

Protected branches in GitHub
PR-based deployment

🔥 Pro Tip 4: Use staging branches

staging-main
production-main

🔥 Pro Tip 5: Use tagging for releases

git tag v1.0
git push origin v1.0

11. FAQ

1. Can I push different code to two repos?

Yes. Use separate local branches.

2. Can I sync both repos automatically?

Yes, but better to control manually for safety.

3. What happens if both repos have different history?

You must:

merge OR
force push carefully

4. Is multi-remote safe?

Yes, if you follow branch discipline.

5. Should I use this in production?

Yes, especially for:

migration
backup
multi-client systems

12. Conclusion

Managing multiple Git repositories is not complex—if you follow the right architecture.

Key Takeaways:

Remote = destination
Branch = code
Always separate codebases using branches
Never mix repositories blindly

Your Action Plan:

Setup origin and old-origin
Create new-main and old-main
Always switch branch before push
Push carefully based on destination

Fix invalid checkpoint record in Postgres

Suyash Sambhare — Tue, 31 Mar 2026 22:10:21 +0000

When PostgreSQL is unable to detect a valid checkpoint from which to begin the recovery procedure, it displays the error "PANIC: could not locate a valid checkpoint record." This may occur if the PostgreSQL container is not restarted safely.

Prevent data corruption

For stateful applications like databases, the first method is to use Stateful Sets rather than Deployments; this is a Kubernetes best practice. To preserve the stability and integrity of your database, Stateful Sets offer assurances regarding the ordering and uniqueness of pods. Additionally, stateful sets will manage restarts more effectively.

The second method is to safely shut down your PostgreSQL instance by using a preStop hook in Kubernetes.
Before a pod is terminated in Kubernetes, the preStop hook is invoked. Once the preStop hook is finished, the pod's termination process starts.

Apply the preStop hook in a Kubernetes configuration for PostgreSQL:

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: postgres
spec:
  replicas: 1
  serviceName: "postgres"
  selector:
    matchLabels:
      app: postgres
  template:
    metadata:
      labels:
        app: postgres
    spec:
      containers:
      - name: postgres
        image: postgres:latest
        ports:
        - containerPort: 5432
        volumeMounts:
        - name: postgres-data
          mountPath: /var/lib/postgresql/data
        lifecycle:
          preStop:
            exec:
              command: ["/bin/sh", "-c", "pg_ctl -D /var/lib/postgres/data -w -t 60 -m fast stop"]
  volumeClaimTemplates:
  - metadata:
      name: postgres-data
    spec:
      accessModes: [ "ReadWriteOnce" ]
      resources:
        requests:
          storage: 1Gi

This preStop hook runs the pg_ctl stop command to shut down the PostgreSQL server.

-D /var/lib/postgres/data option specifies the directory where the data base files live,
-w waits until the server shuts down,
-t 60 specifies the wait timeout in seconds, and
-m fast means to do a "fast" shutdown, which rolls back all active transactions, disconnects clients immediately and shuts down.

For AWS ECS deployments you can set the Min and max running tasks respectively: 0% min and 100% max

Recover from an error state

This can be fixed by running pg_resetwal command by connecting to the container.
However, since the pod is in crashLoopBackOff state, we will not be able to connect to the container.
We must first make the pod to be in stable state to execute the command.

Please follow the steps below for manual execution of the command pg_resetwal in a container.
This process requires the pod to be in a stable state, and not in a crash loop.
You can achieve this by introducing a delay in the postgres-deployment.yaml file.

Scale down the deployment by reducing the replica count of the deployment to zero using the following command: kubectl scale deployment postgres - replicas=0
Introduce a delay: Modify the postgres-deployment.yaml file to include a sleep command that delays the initialization process by 600 seconds, keeping the pod in the initializing state.

Here is an example of how to add it:

spec:
      containers:
      - name: postgres
        image: postgres:latest
        command: [ "/bin/bash", "-c", " - " ] 
        args: [ "sleep 600;" ]

Scale up the deployment: Bring the deployment back up by increasing the replica count to one using the following command: kubectl scale deployment postgres - replicas=1
Execute pg_resetwal in the pod: Once the pod reaches the initializing state, run the pg_resetwal command by executing into the pod. Here is how you can do this:

kubectl exec -it postgres - /bin/bash
su postgres
pg_resetwal /var/lib/postgres/data

Proceed despite the warning: If you do receive the warning, continue the process by forcing the pg_resetwal command as follows: pg_resetwal /var/lib/posgtgres/data -f

After running this command, you should receive a confirmation message stating “Write-ahead log reset.”
After you have successfully executed the pg_resetwal command, you should be able to restart the PostgreSQL server.
Remember that the pg_resetwal command is a measure of last resort and carries the risk of data loss or inconsistency.
Always make sure to maintain regular backups of your PostgreSQL databases and consider setting up high availability and replication solutions for your production databases.

Ref: https://medium.com/@adnanitdev/fix-for-error-panic-could-not-locate-a-valid-checkpoint-record-in-postgres-or-citus-running-in-b03d8341a258

Different kind of prompt used by Spring AI

rakesh kumar — Fri, 27 Mar 2026 06:17:45 +0000

Main kinds of prompts Spring AI helps you make
A. System prompt

This tells the model how to behave.

Examples:

“You are a helpful banking assistant.”
“Answer in simple English.”
“Do not return unsafe medical advice.”

Role: controls tone, style, rules, and boundaries. Spring AI docs say system messages are generated by the system to guide the conversation.

B. User prompt

This is the actual question or request from the user.

Examples:

“What is compound interest?”
“Summarize this document.”
“Translate this to Hindi.”

Role: carries the direct input to the model. Spring AI identifies user messages as the direct inputs from the user.

C. Multi-message chat prompt

This combines multiple messages together, usually:

one or more system messages
one user message
sometimes previous conversation messages

Role: gives the model better context than a single plain text prompt. Spring AI’s prompt model is message-based, not just one raw string.

D. Template prompt / parameterized prompt

This is a prompt with placeholders like {name}, {topic}, {question}.

Examples:

“Explain {topic} to a beginner.”
“Write an email to {customerName} about {issue}.”

Role: makes prompts reusable and dynamic. The docs note that prompts often contain placeholders substituted at runtime. The prompt docs also compare this to a view template or SQL with placeholders.

E. External file prompt

You can keep prompts outside Java code in template files instead of hardcoding them. That makes them reusable and easier to version and maintain. Your screenshot mentions .st, .mustache, and .ftl, and Spring AI’s docs show PromptTemplate rendering support, including the default StPromptTemplate based on StringTemplate.

F. RAG prompt

This is used when you want the model to answer using retrieved context from documents or a vector database. Spring AI’s RAG support lets you customize a PromptTemplate that merges the user query with retrieved context, and the docs specify placeholders such as query and question_answer_context.

G. Memory-aware prompt

LLMs are stateless by default, so Spring AI adds chat memory features to carry useful prior context into later interactions. This helps create prompts that include conversation context without you manually rebuilding it each time.

2) Why these prompt types matter

Different prompt types solve different problems:

System prompt → behavior and rules
User prompt → actual request
Template prompt → reuse and dynamic input
RAG prompt → answer from documents/context
Memory-aware prompt → continue a conversation naturally

That is why Spring AI is useful: it gives structure around prompt creation instead of making you manually assemble raw HTTP JSON every time. ChatClient builds prompt parts fluently, and Advisors can add memory, retrieved documents, and more advanced behavior.

3) Coding examples

These examples are written in the normal Spring AI style and may need small adjustment depending on your exact Spring AI version.

Example 1: Simple system prompt + user prompt

@RestController
@RequestMapping("/ai")
public class ChatController {

    private final ChatClient chatClient;

    public ChatController(ChatClient.Builder builder) {
        this.chatClient = builder.build();
    }

    @GetMapping("/explain")
    public String explain(@RequestParam String topic) {
        return chatClient.prompt()
                .system("You are a Java teacher. Explain in simple English.")
                .user("Explain this topic for a beginner: {topic}")
                .param("topic", topic)
                .call()
                .content();
    }
}

What happens here

.system(...) creates a system prompt
.user(...) creates a user prompt
.param(...) fills the template placeholder dynamically

This matches the docs’ message-based prompt model and runtime placeholder substitution.

Example 2: Reusable template prompt

@Service
public class EmailPromptService {

    private final ChatClient chatClient;

    public EmailPromptService(ChatClient.Builder builder) {
        this.chatClient = builder.build();
    }

    public String generateEmail(String customerName, String issue) {
        return chatClient.prompt()
                .system("You are a professional customer support writer.")
                .user("""
                      Write a polite support email to {customerName}.
                      The issue is: {issue}
                      Keep the tone professional and short.
                      """)
                .param("customerName", customerName)
                .param("issue", issue)
                .call()
                .content();
    }
}

Why this is useful

Same prompt structure, different values. That is the main idea of template prompts. Spring AI docs explicitly describe placeholders being replaced based on user requests or application code.

Example 3: Prompt from external template file idea

Suppose you keep a prompt file like:

src/main/resources/prompts/greeting.st

Hello, my name is {name}. Can you greet me back nicely?

Then your code can render and send it through Spring AI. A simplified example:

@Service
public class GreetingService {

    private final ChatClient chatClient;

    public GreetingService(ChatClient.Builder builder) {
        this.chatClient = builder.build();
    }

    public String greet(String name) {
        String template = "Hello, my name is {name}. Can you greet me back nicely?";

        return chatClient.prompt()
                .user(template)
                .param("name", name)
                .call()
                .content();
    }
}

Spring AI supports prompt templating and documents PromptTemplate; for RAG templates it uses StPromptTemplate by default, based on StringTemplate.

Example 4: RAG-style prompt

String answer = chatClient.prompt()
        .system("Answer only from the provided context. If unsure, say you do not know.")
        .user("""
              Question: {question}

              Context:
              {context}
              """)
        .param("question", "What is the refund policy?")
        .param("context", """
                Refunds are allowed within 7 days of purchase
                if the product has not been activated.
                """)
        .call()
        .content();

This is the basic idea behind a RAG prompt: merge the user query with retrieved context. Spring AI’s RAG docs describe custom templates that combine query and retrieved context for answering.

Example 5: Memory-aware chat idea

String response = chatClient.prompt()
        .system("You are a helpful assistant that remembers prior discussion context.")
        .user("Continue our last discussion and summarize the final decision.")
        .call()
        .content();

In real apps, chat memory is usually backed by Spring AI chat memory support, because LLMs are stateless by default and Spring AI adds memory abstractions to maintain useful context.

Very simple summary

Spring AI mainly helps you create these prompt types:

System prompts
User prompts
Multi-message prompts
Template prompts
External-file prompts
RAG prompts
Memory-aware prompts

So the big benefit is not just “send text to GPT.”
The real benefit is: Spring AI gives prompt structure, reuse, context, and maintainability inside a Spring Boot application

How Spring AI Simplifies REST API Integration in Modern Applications

rakesh kumar — Fri, 27 Mar 2026 05:30:34 +0000

Theory explanation
Why not call REST API directly from controller?
Main purpose of Spring AI interface
Why this helps in modern applications
Simple flow
Coding example

Theory explanation

In a normal Spring Boot project, you can call an AI provider directly with REST APIs.
That means your code builds HTTP requests, adds headers, sends JSON, handles authentication, parses responses, and manages retries by itself.

That works for small demos, but in modern applications it becomes repetitive and hard to maintain.

Spring AI simplifies this by putting a Spring-style abstraction layer between your application and the AI provider. Instead of writing low-level HTTP code everywhere, you work with higher-level APIs such as ChatClient, ChatModel, Prompt, and advisors. The Spring AI reference describes ChatClient as a fluent API for communicating with an AI model, where prompts are built from messages like user and system messages.

So the difference is:

REST API only = low-level transport and manual integration
Spring AI = structured, reusable, Spring-friendly AI integration built on top of provider APIs

Why not call REST API directly from controller?

Because controller should mainly handle:

incoming request
validation
response

If controller also manages:

AI API payloads
prompt structure
JSON parsing
retries
embeddings
vector DB lookup

then controller becomes overloaded.

Spring AI keeps the design cleaner.

Main purpose of Spring AI interface

It hides low-level HTTP complexity

You do not need to manually build every REST request.

Instead of this:

create URL
create headers
add API key
build JSON
send request
parse result

You can use a cleaner Spring-style approach.

It gives a Spring-friendly programming model

In Spring Boot, developers like:

dependency injection
beans
service classes
reusable configuration

Spring AI fits that style.

So AI feels like a normal Spring service, not like raw external API handling.

Example idea:

ChatClient
EmbeddingModel
PromptTemplate

These are easier to use in service classes.

It reduces vendor lock-in

Different providers have different request and response formats.

Without Spring AI:

OpenAI code looks one way
another provider looks different
switching providers means code change in many places

With Spring AI:

you work through a common abstraction
changing provider becomes easier

It supports AI-specific features, not just REST calling

AI integration is not just sending text over HTTP.

It often includes:

prompt templating
chat memory
embeddings
vector search
RAG flow
structured output
model options

REST API does not give these patterns automatically.

Spring AI provides structure for them.

It makes enterprise code cleaner

In small demo projects, direct REST calls are okay.

But in real applications:

chatbot
recommendation engine
support assistant
document Q&A
healthcare AI assistant

you need better architecture.

Spring AI helps separate:

controller
business logic
AI interaction
prompt layer
retrieval layer

That makes the project easier to scale.

Why this helps in modern applications

Cleaner code

Without Spring AI, you often repeat:

API URL handling
auth token or API key setup
request body creation
response parsing
provider-specific JSON mapping

Spring AI centralizes that interaction. Its model API is designed as a portable interface across providers, which makes the code cleaner and more maintainable.

Easier provider switching

If you call one provider directly using raw REST, your code usually becomes tightly coupled to that provider’s request and response format.

Spring AI’s Chat Model API is designed to be portable, so moving across supported providers requires fewer code changes than rewriting raw REST integration everywhere.

Prompt handling becomes structured

Modern AI apps need more than one plain input string. They need:

system instructions
user prompts
templates
placeholders
context injection

Spring AI supports prompts as structured message collections and supports prompt templating, which is much better than building JSON strings manually for each REST call.

Better support for advanced AI patterns

Modern applications often need:

chat memory
embeddings
RAG
tool calling
streaming responses

Spring AI supports these patterns directly through its APIs and advisors, which is far beyond “just send a REST request.”

Better fit with Spring Boot architecture

Spring developers prefer:

dependency injection
beans
service classes
configuration properties
starter-based setup

Spring AI fits naturally into that model. For example, the official docs provide Spring Boot starter-based configuration such as spring-ai-starter-model-openai, and the getting-started docs state support for Spring Boot 3.4.x and 3.5.x.

Simple flow

Direct REST approach

Controller → Service → Manual HTTP Client → AI Provider API

Spring AI approach

Controller → Service → ChatClient / ChatModel → AI Provider API

Spring AI still uses provider APIs underneath, but your application code stays much simpler.

Coding example

Below is a simple Spring Boot example using Spring AI with OpenAI-style integration.

1) Maven dependencies

<dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>org.springframework.ai</groupId>
            <artifactId>spring-ai-bom</artifactId>
            <version>YOUR_VERSION</version>
            <type>pom</type>
            <scope>import</scope>
        </dependency>
    </dependencies>
</dependencyManagement>

<dependencies>
    <dependency>
        <groupId>org.springframework.ai</groupId>
        <artifactId>spring-ai-starter-model-openai</artifactId>
    </dependency>

    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-web</artifactId>
    </dependency>
</dependencies>

The official Spring AI OpenAI chat docs show spring-ai-starter-model-openai as the starter artifact.

2) application.properties

spring.ai.openai.api-key=YOUR_API_KEY
spring.ai.openai.chat.options.model=gpt-4o-mini

Spring AI provides Spring Boot auto-configuration for the OpenAI chat client through properties under the Spring AI namespace.

3) Service class

package com.example.demo.service;

import org.springframework.ai.chat.client.ChatClient;
import org.springframework.stereotype.Service;

@Service
public class AiService {

    private final ChatClient chatClient;

    public AiService(ChatClient.Builder builder) {
        this.chatClient = builder.build();
    }

    public String explainTopic(String topic) {
        return chatClient.prompt()
                .system("You are a helpful Java and Spring expert. Explain in simple English.")
                .user("Explain this topic in a modern application context: {topic}")
                .param("topic", topic)
                .call()
                .content();
    }
}

This uses ChatClient’s fluent API to build a prompt from system and user messages, with runtime parameters. That is exactly the sort of prompt-building model described in the official docs.

4) REST controller

package com.example.demo.controller;

import com.example.demo.service.AiService;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RequestParam;
import org.springframework.web.bind.annotation.RestController;

@RestController
public class AiController {

    private final AiService aiService;

    public AiController(AiService aiService) {
        this.aiService = aiService;
    }

    @GetMapping("/api/explain")
    public String explain(@RequestParam String topic) {
        return aiService.explainTopic(topic);
    }
}

Now your application exposes a normal REST endpoint, but internally it uses Spring AI rather than a manually coded HTTP call to the model provider.

How to integrate AI models into Spring Boot applications using Spring AI

rakesh kumar — Fri, 27 Mar 2026 03:39:18 +0000

What is Spring AI?
Spring AI Architecture
Purpose of Spring AI
Role of Spring AI
How Flow Works
Common Questions (with Answers)

What is Spring AI?

Spring AI is a framework that helps developers integrate AI models (like GPT, LLMs, embeddings, etc.) into Spring Boot applications easily.

Instead of manually calling AI APIs and handling complexity, Spring AI provides:

Clean Java-based abstraction
Easy integration with AI providers (OpenAI, Azure, etc.)
Support for chat, embeddings, vector DB, prompt templates

👉 In simple words:

Spring AI = Bridge between Spring Boot apps and AI models

🎯

Spring AI Architecture

How Spring AI Works

Users give input to Spring Boot REST controller.
Spring AI processes the user input using Prompt Templates or ChatClient (to call LLM)
ChatClient connects to external AI providers (OpenAI, Ollama, etc.)
And response is returned to the Spring Boot app and sent back to the user . Multi-Provider Support: Spring AI framework supports connecting to multiple LLM providers like

OpenAI (ChatGPT)
Azure OpenAI
Hugging Face (Transformers)
Ollama (for local models)

Chat Client API: Standardizes communication with LLMs using a fluent API, regardless of provider differences.

Prompt Templates: Developers can define dynamic prompts with variables using Spring Expression Language (SpEL).

Embedding and Vector Store Integration: Spring AI supports converting text into embeddings like numeric vector and storing them in vector databases like PostgreSQL with pgvector.

Structured Outputs ( Like POJO Mapping): Spring AI model output (like JSON) directly to the Java POJOs class using annotations and converters.

Features of Spring AI

Purpose of Spring AI

The main purpose is to simplify AI integration in enterprise Java applications.

Key Goals:

Reduce boilerplate code for AI API calls
Provide standardized APIs (like Spring Data, Spring MVC)
Enable production-ready AI apps
Support scalable and maintainable architecture

🧩

Role of Spring AI

AI Integration Layer Connects your Spring Boot app with AI models Handles API calls, authentication, retries
Abstraction Provider You don’t write raw HTTP calls Use simple Java interfaces
Prompt Management Helps structure prompts cleanly Supports templates
Data Handling (Vector + Embeddings) Store & search semantic data Used in RAG (Retrieval-Augmented Generation)
Enterprise Enablement Works with microservices Secure, scalable, production-ready 🏗️ Architecture (Colorful + Labeled Representation)

How Flow Works

User sends request → Frontend
Request hits → Spring Boot Controller
Service calls → Spring AI layer
Spring AI sends request → AI Model (GPT)
AI response → back to Spring Boot → UI

❓

Common Questions (with Answers)

Why use Spring AI instead of direct API calls?

👉 Because it reduces complexity, gives structure, and is production-ready.

Can Spring AI work with Laravel backend?

👉 No directly. Spring AI is for Java ecosystem.
For Laravel, you use OpenAI SDK or HTTP APIs manually.

Is Spring AI suitable for microservices?

👉 Yes, very suitable. You can create:

AI microservice
Chat service
Recommendation engine

What features does Spring AI provide?

Chat completion
Embeddings
Prompt templates
Vector DB integration
RAG support

When should you choose Spring AI?

👉 Choose it when:

Your backend is Spring Boot
You need enterprise AI integration
You want clean, scalable architecture

When NOT to use Spring AI?

👉 Avoid if:

Your backend is Laravel/PHP
Small project (simple API call enough)
🔥 Final Simple Summary

Purpose: Simplify AI integration
Role: Bridge Spring Boot ↔ AI Models
Benefit: Clean, scalable, enterprise-ready AI apps

Reference
utube

WhatsApp vs SMS Pricing in India: Complete Guide for OTP, Marketing & Notifications (2026)

Abhishek singh — Tue, 24 Mar 2026 05:31:23 +0000

WhatsApp vs SMS Pricing in India: Complete Guide for OTP, Marketing & Notifications (2026)

Introduction

If you're building a product, SaaS platform, or customer communication system in India, one question always comes up:

Should I use WhatsApp or SMS for sending OTPs, marketing messages, or notifications?

At first glance, both seem similar — they deliver messages to users. But when you go deeper, you’ll realize:

Pricing models are completely different
Use cases vary significantly
Cost impact can be huge at scale

This guide will give you a complete, practical, and real-world understanding of:

WhatsApp pricing (Meta direct)
SMS pricing (Twilio India)
Cost comparison for OTP, marketing, and notifications
Best strategy for your business

By the end, you won’t need any other resource.

What is WhatsApp Business API?
What is SMS (Twilio)?
WhatsApp Pricing Model (India)
SMS Pricing Model (India)
WhatsApp vs SMS Cost Comparison Table
OTP Pricing Comparison
Marketing Pricing Comparison
Notification Pricing Comparison
Real-Life Use Cases
Best Practices
Common Mistakes to Avoid
FAQs
Conclusion

1. What is WhatsApp Business API?

WhatsApp Business API (Meta) allows businesses to send:

OTPs (Authentication)
Notifications (Utility)
Marketing campaigns
Customer support messages

Key Features:

Rich media (images, buttons, links)
Two-way communication
High engagement rates
Template-based messaging

2. What is SMS (Twilio)?

SMS is the traditional way to send messages using telecom networks.

With Twilio, you can:

Send OTPs
Send alerts
Run marketing campaigns

Key Features:

Works on all phones
No internet required
Simple implementation

3. WhatsApp Pricing Model (India)

WhatsApp pricing is not fixed per message. It depends on:

Message Categories:

Authentication (OTP)
Utility (notifications)
Marketing
Service (support replies)

Important Rules:

Service messages = FREE (within 24 hours)
User replies open a 24-hour window
Charges apply only for template messages outside window

Approx Pricing (India):

Category	Approx Cost (INR)
Authentication (OTP)	₹0.30 – ₹0.80
Utility (Notification)	₹0.20 – ₹0.60
Marketing	₹0.80 – ₹2.50
Service (Reply)	FREE

4. SMS Pricing Model (India)

SMS pricing is simple but expensive.

Twilio India Pricing:

$0.0832 ≈ ₹7.8 per SMS segment

Important Points:

Charged per segment (160 characters)
Long messages = multiple SMS charges
No free window

5. WhatsApp vs SMS Cost Comparison Table

Use Case	WhatsApp Cost (INR)	SMS Cost (INR)	Winner
OTP	₹0.30 – ₹0.80	₹7.80	WhatsApp
Marketing	₹0.80 – ₹2.50	₹7.80+	WhatsApp
Notification	₹0.20 – ₹0.60	₹7.80	WhatsApp
Support Reply	FREE	₹7.80	WhatsApp

6. OTP Pricing Comparison

WhatsApp OTP:

Category: Authentication
Cost: ~₹0.30 – ₹0.80

SMS OTP:

Cost: ~₹7.80 per SMS

Example:

If you send 1000 OTPs:

Channel	Total Cost
WhatsApp	₹300 – ₹800
SMS	₹7800

Insight:

👉 WhatsApp is 10x cheaper for OTP

7. Marketing Pricing Comparison

WhatsApp Marketing:

Cost: ₹0.80 – ₹2.50
Includes:
- Buttons
- Images
- Links

SMS Marketing:

Cost: ₹7.80+
Plain text only

Example (1000 messages):

Channel	Total Cost
WhatsApp	₹800 – ₹2500
SMS	₹7800+

Insight:

👉 WhatsApp gives better ROI + lower cost

8. Notification Pricing Comparison

WhatsApp Notification:

Utility messages
Cost: ₹0.20 – ₹0.60
FREE if within support window

SMS Notification:

Cost: ₹7.80

Example (1000 messages):

Channel	Total Cost
WhatsApp	₹200 – ₹600
SMS	₹7800

Insight:

👉 Notifications are extremely cheap on WhatsApp

9. Real-Life Use Cases

Case 1: E-commerce Platform

Order confirmation → WhatsApp
Delivery updates → WhatsApp
Backup → SMS (if WhatsApp fails)

Case 2: Banking App

OTP → WhatsApp + SMS fallback
Alerts → WhatsApp

Case 3: SaaS Platform

Login OTP → WhatsApp
Notifications → WhatsApp
Marketing → WhatsApp campaigns

10. Best Practices

1. Use Hybrid Strategy

Primary: WhatsApp
Fallback: SMS

2. Optimize Message Length

SMS charges per segment

3. Use WhatsApp Templates Smartly

Avoid unnecessary marketing messages

4. Track Delivery Rates

Improve ROI

5. Use Automation

Trigger-based messaging

11. Common Mistakes to Avoid

❌ Sending all messages via SMS
❌ Ignoring WhatsApp free window
❌ Not using fallback system
❌ Sending long SMS (cost increases)
❌ Poor template approval strategy

12. FAQs

1. Is WhatsApp cheaper than SMS in India?

Yes, 5x–20x cheaper depending on use case.

2. Can WhatsApp replace SMS completely?

No, because:

Some users don’t use WhatsApp
SMS is still needed as fallback

3. Which is better for OTP?

👉 WhatsApp (cost) + SMS (reliability)

4. Are WhatsApp replies free?

Yes, within 24-hour service window

5. Why is SMS expensive?

Because it uses telecom networks + carrier charges

13. Conclusion

If you are building a modern application in India:

Best Strategy

Use WhatsApp as primary channel
Use SMS as backup only

Final Comparison:

WhatsApp = Cheap + Rich + Interactive
SMS = Expensive + Basic + Reliable

Actionable Advice:

Start with:

WhatsApp OTP system
WhatsApp notifications
SMS fallback

This will:

Reduce cost by 80–90%
Improve user experience
Increase engagement

How to use Codex for Coding?

Rajesh Kumar — Thu, 19 Mar 2026 13:29:24 +0000

================================

📁 Project Context

================================

Directory Structure:
-- /desd/dsds/dsds/dsd

Artifacts:

Database Schema: hospital.sql
Model: xgay.php
Controller: ddsadad.php
View: dskjsahdkja.php

================================

🎯 Role Definition

================================

Act as a senior software engineer with 15+ years of experience in:

PHP (Core + Laravel)
MySQL (schema design, indexing, query optimization)
Data Structures & Algorithms
Application Security (OWASP best practices)
Performance optimization (backend + frontend)
JavaScript (UX, async flows)

Your responses should be:

Practical and production-ready
Performance-conscious
Secure by design
Clean and maintainable

================================

🧩 Task 1: Code Review

================================

Objective:
Review the current implementation of the search filter.

Instructions:

Analyze the existing search/filter logic across model, controller, and view
Identify:
- Code quality issues
- Performance bottlenecks
- Security risks (SQL injection, validation gaps, etc.)
- Scalability concerns
Suggest improvements with reasoning

Action:
READ the provided files and give structured feedback.

================================

🧩 Task 2: Feature Design (Read-Only)

================================

Objective:
Extend the search filter with additional fields:

City
State
Country

Instructions:

Do NOT implement code yet
Provide:
- Step-by-step approach
- Required changes in:
- Database (if needed)
- Model
- Controller
- View/UI
- Query optimization strategy (indexes, joins, etc.)
- Validation and security considerations
- UX recommendations

Action:
Proceed ONLY after reviewing Task 1 feedback.

================================

🧩 Task 3: Conditional Implementation

================================

Condition A (If approach is approved):

Implement the feature end-to-end
Ensure:
- Clean, modular code
- No performance degradation
- Proper indexing and optimized queries
- Secure input handling
- Excellent UX (fast, intuitive filtering)
You may refer to any file as needed

Condition B (If approach is NOT approved):

Refine the design
Provide alternative approaches
Continue iteration until a satisfactory solution is reached

================================

⚠️ Important Guidelines

================================

Always think before coding
Prefer optimized queries over brute-force filtering
Avoid N+1 query problems
Follow Laravel best practices (if applicable)
Keep separation of concerns (MVC clean)
Suggest improvements beyond the asked scope if valuable

Debug School

Windows 11 context menu

Ye Olde Right Click menu

Le New Right Click Menu

Google Sign-In on Play Store — Troubleshooting Guide

Google Sign-In on Play Store — Troubleshooting Guide

1. Symptoms

2. Why it happens — the root cause

3. Architecture: where SHA-1s need to be

4. The fix — step by step

Step 1 — Get the App signing key SHA-1 from Play Console

Step 2 — Add a new Android OAuth client in Google Cloud Console

Step 3 — Verify OAuth consent screen is published

Step 4 — Confirm the Web client ID in Flutter code

Step 5 — Test

5. Verifying you actually fixed it

6. Common pitfalls

Pitfall: copied the Upload key SHA-1 instead of App signing key

Pitfall: deleted the old Android client

Pitfall: pasted the SHA-1 into the wrong Cloud project

Pitfall: tried to "Link Cloud project" in Play Console and got "Project not found"

Pitfall: still in Testing mode

Pitfall: passing the Android client ID as serverClientId

Pitfall: google-services.json references the wrong project

7. When this guide doesn't apply

8. Reference: this repo's exact configuration (post-fix)

9. Quick-start checklist for future apps

10. Reusing this guide

Why Google Sign-In Works on Your Emulator But Breaks on Play Store

Why Google Sign-In Works on Your Emulator But Breaks on Play Store — and How to Fix It in 5 Minutes

The Bug That Only Shows Up After You Ship

Three Signatures, One Confused OAuth Client

Symptoms That Lead Everyone Astray

The Fix, Plain and Simple

Step 1 — Get the App Signing key SHA-1 from Play Console

Step 2 — Register a new Android OAuth client with that SHA-1

Step 3 — Make sure your OAuth consent screen is published

Step 4 — Verify your Flutter code uses the Web client ID

Step 5 — Test

How to Verify You Actually Fixed It

Pitfalls Worth Calling Out

A Lesson In Distributed Trust

Closing

Win Updates via PS1

AWS Secrets Manager in GitLab CI/CD

Using AWS Secrets Manager in GitLab CI/CD

How the Integration Works (Architecture)

Authentication Methods

1. IAM Role

2. OpenID Connect

Defining Secrets in Jobs

Standard Form

Working with Full JSON Secrets

Secret Versioning

Cross‑Account Access

Per‑Secret Overrides (Advanced)

File vs Variable (file: true | false)

Use AWS Secrets Manager secrets in GitLab CI/CD

Use AWS Secrets Manager secrets in a CI/CD job

With IAM Role authentication

With OpenID Connect authentication

Short form syntax

Secret versioning

Cross-account secret access

Per-secret configuration overrides

Troubleshooting

Error: no EC2 IMDS role found

Git Multi-Remote Workflow:It Multiple Remote Management Guide

🚀 Git Multi-Remote Workflow: How to Manage and Push Code to Multiple Repositories (origin & old-origin) Like a Pro

Introduction

Table of Contents

1. What is Multi-Remote in Git

2. Understanding origin vs old-origin

3. Core Concept: Code vs Remote (MOST IMPORTANT)

Reality:

4. Real Workflow Scenarios

Scenario 1: Push same code to both repos

Scenario 2: Different code in both repos

5. Step-by-Step Implementation (Production Setup)

Step 1: Add both remotes

Pitfall: passing the Android client ID as `serverClientId`

Pitfall: `google-services.json` references the wrong project

File vs Variable (`file: true | false`)

Error: `no EC2 IMDS role found`