Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Report all refreshCheck() outcomes and entry gist #1932

Closed
wants to merge 1 commit into from
Closed

Report all refreshCheck() outcomes and entry gist #1932

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
7 changes: 5 additions & 2 deletions src/refresh.cc
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -265,7 +265,7 @@ refreshCheck(const StoreEntry * entry, HttpRequest * request, time_t delta)
else if (request)
uri = request->effectiveRequestUri();

debugs(22, 3, "checking freshness of URI: " << uri);
debugs(22, 3, "checking freshness of " << *entry << " with URI: " << uri);

// age is not necessarily the age now, but the age at the given check_time
if (check_time > entry->timestamp)
Expand Down Expand Up @@ -480,11 +480,14 @@ refreshCheck(const StoreEntry * entry, HttpRequest * request, time_t delta)
}

#endif
debugs(22, 3, "returning STALE_EXPIRES");
return STALE_EXPIRES;
}

if (sf.max)
if (sf.max) {
debugs(22, 3, "returning STALE_MAX_RULE");
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Some existing debugs() in this function already use this (correct) minimalist style to report outcomes.

Some debugs() also add "YES/NO prefixes that are rather misleading for a non-boolean function that is not called something like isFresh(). Some debugs() also try to explain why a particular outcome was reached by describing the last condition checked, but such reporting can easily mislead because all but the very first outcome depend on multiple preconditions. For the two return statements reported in this PR, just letting the developer know which exit path got triggered is the best strategy IMO.

return STALE_MAX_RULE;
}

if (sf.lmfactor) {
#if USE_HTTP_VIOLATIONS
Expand Down