What is flash scope in a web framework, and how does it differ from a plain session attribute?
answer
- for the write-then-redirect pattern
- lives one hop, not forever
- the framework removes it, not your code
- small message, serialized with the session
basics
~20 sFlash scope holds a value written on one request and exposed to the next, after which the framework discards it without any delete call. A plain session attribute stays until code removes it, so it would reappear on later pages.
solid answer
~40 sFlash scope exists for the write-then-redirect pattern: the request that performs the work answers with a redirect, so a different request renders the result and needs the outcome message. A value put in the flash is carried across that one redirect, exposed to the next request, and then discarded by the framework without anybody calling remove. A plain session attribute has no such rule — it lives until code deletes it or the session ends, so a success message stored there follows the user around. Flash entries usually ride inside the session's own storage, which means they are serialized and should stay small: a short message or a key, not an object graph.
go deeper
Remember the shape: write the message, redirect, the next page shows it, the framework throws it away. A plain session attribute would keep showing it until you removed it yourself.
Explain where the entry physically lives and why it is serialized with the session, and be ready to say what happens when the handler renders instead of redirecting.
Talk about what breaks in production: a background or asset request consuming the hop, two redirects in a chain, two tabs sharing one session, and how you would instrument the write and the read.
Position it as a deliberately tiny, lossy channel. Anything that must not be lost between two requests belongs in durable state, and treating flash as workflow storage is how a redirect chain becomes untestable.
## The problem flash scope solves When a handler changes something and answers with a redirect, the request that did the work is **not** the request that renders the page the user sees. The work request has an outcome to report — saved, deleted, five rows skipped — and no page to put it on. There are only three places that outcome can travel: - **in the redirect target's query string** — visible in the address bar, shareable, forgeable, and it survives a refresh forever; - **in the session as an ordinary attribute** — survives, but nothing removes it, so it is shown again on the next page and the one after; - **in the flash** — survives exactly one hop and is then gone. Flash scope is the framework's name for the third option. It exists because "remember this for precisely one more request" is a genuinely common need and an easy thing to get wrong by hand. ## What a flash entry actually is A flash entry is a value written during request A that the framework: 1. persists alongside the session, so it survives the gap between two requests; 2. makes readable to request B, the next request from the same client; 3. removes, so request C never sees it — without the handler calling any delete. That third step is the whole feature. Everything else a session attribute already does. | | Flash entry | Plain session attribute | |---|---|---| | Lifetime | one following request | until removed or the session ends | | Who clears it | the framework | your code | | Typical content | a short outcome message or key | identity, preferences, workflow state | | Repeat display risk | none by construction | shown again on every later page | | Survives a refresh of the target page | no | yes | ## Where the boundaries are fuzzy Frameworks differ on when exactly the entry disappears. Some delete it the moment it is read; others mark it on arrival and sweep it at the end of that request whether or not anything read it. The difference is visible when the next request does not render a page — if the very next request from that client is a background poll or an asset fetch handled by the framework, a sweep-at-end-of-request implementation can consume the message before the page the user is waiting for ever loads. Some frameworks also offer a **keep** or **reflash** operation that puts the entry back for one more hop. That is the escape hatch for a chain of two redirects; reaching for it repeatedly means the value is not really a flash value. ## Practical rules - **Keep it small and simple.** Flash entries are serialized with the session, so store a message string or a code the next page resolves, not a loaded object graph. - **Only write it when you are about to redirect.** Writing flash and then rendering directly means the entry is still waiting, and it lands on whatever request comes next. - **Do not use it as a one-request cache.** If the next page needs data, fetch it there; flash is for what cannot be recomputed, namely what just happened. - **Never put anything in it the user must not be able to lose.** The user can close the tab between the two requests, and the entry evaporates. - **Remember it is per session, not per tab.** Two tabs share one session, so a message written by one can be consumed by the other. ## Why interviewers ask it It is a short question with a long tail. Candidates who have only stored a message in the session answer the first half and then cannot say who removes it; candidates who have actually shipped the pattern immediately mention the redirect, the one-hop rule and the size limit. It also opens naturally onto harder ground: what happens with concurrent requests, what happens across two redirects, and what happens when the session is not saved. ## Deciding it is really a flash value Three questions settle it before you reach for the mechanism: - **Must it survive a refresh of the target page?** Then it is not a flash value; the entry is already gone by then. - **Is more than one later page going to need it?** Then it is workflow state, and belongs in an attribute you remove yourself. - **Does anything break if the user closes the tab between the two requests?** Then it is load-bearing data and must not live in a single-hop, best-effort slot.
- Why not pass the outcome message in the redirect target's query string instead?Because it becomes part of a shareable, bookmarkable address: it survives refreshes, shows up in logs and history, and any client can craft a page that displays a message you never produced. The flash keeps the value server-side and disposes of it after one hop.
- What does a keep or reflash operation do, and when is it a smell?It re-marks an entry so it survives one more request, which is the honest fix for a two-hop redirect chain. Needing it routinely means the value is workflow state rather than a one-off message, and belongs in a session attribute you remove deliberately.
- A handler writes a flash entry and then renders a page directly instead of redirecting. What does the user see?Not that message on the current page — the entry is written for the next request. It stays pending and appears on whatever that client requests next, which may be an unrelated page, so the message shows up in the wrong place.
A note left on the counter for whoever walks in next, who reads it and takes it away. Anyone who comes through the door first gets the note, which is also how it ends up on the wrong page.
saying these in an interview costs you the question
- Thinks a flash entry is visible on the same response that wrote it
- Says the handler must delete the flash entry itself afterwards
- Treats flash scope as a general one-request cache for page data
- Believes the value travels in the redirect address rather than server-side
- Assumes flash is per browser tab rather than per session