Different etag is returned for same response when sent with different installation access tokens from the same app

[gr2m]

Select Topic Area

Question

Body

I'm not sure if this is a bug or by design. I would expect the value for the etag response header to be calculated based on the response body. And in fact it works as expected as long as the same token is used. However, when authenticating as a GitHub Application, the etag changes each time the installation access token changes.

Here is a minimal test case: https://runkit.com/gr2m/etag-changes-for-same-github-app-but-different-installation-access-token/1.0.0

code & output

Code

const { App, Octokit } = require("octokit")

main();

async function main() {
  const app = new App({
    appId: process.env.GITHUB_APP_ID,
    privateKey: process.env.GITHUB_APP_PRIVATE_KEY.replace(/\\n/g, "\n"),
  });

  const { data: appInfo } = await app.octokit.request("GET /app");
  console.log(`Authenticated as ${appInfo.html_url}`);

  const [firstInstallation] = await app.octokit.paginate(
    "GET /app/installations"
  );
  console.log(
    `Installation ID #${firstInstallation.id} for ${firstInstallation.account.login}`
  );

  const installationAuth1 = await app.octokit.auth({
    type: "installation",
    installationId: firstInstallation.id,
    refresh: true,
  });
  const installationAuth2 = await app.octokit.auth({
    type: "installation",
    installationId: firstInstallation.id,
    refresh: true,
  });

  // verify that tokens are different
  console.log(
    `Tokens are different: ${
      installationAuth1.token !== installationAuth2.token
    }`
  );

  // get etag for the same endpoint twice using the same token
  const octokit1 = new Octokit({
    auth: installationAuth1.token,
  });
  await check(1, firstInstallation.id, octokit1, installationAuth1.token);
  await check(2, firstInstallation.id, octokit1, installationAuth1.token);

  // ... and then again for the other token
  const octokit2 = new Octokit({
    auth: installationAuth2.token,
  });
  await check(3, firstInstallation.id, octokit2, installationAuth2.token);
  await check(4, firstInstallation.id, octokit2, installationAuth2.token);
}

async function check(number, id, octokit, token) {
  const {
    headers: { etag: etag1 },
  } = await octokit.request("GET /orgs/{org}/repos", {
    org: "community",
  });

  console.log(
    `Check ${number}: installtion #${id} got etag ${etag1} for token ending in ${token.slice(
      -5
    )}`
  );
}

Output

Authenticated as https://github.com/apps/gr2m
Installation ID #18899821 for gr2m
Tokens are different: true
Check 1: installation #18899821 got etag W/"100eeb8bdaa2153100a11b84495ea1e54acdb6ffe2e83824a3708070c4035031" for token ending in 1I9pZ
Check 2: installation #18899821 got etag W/"100eeb8bdaa2153100a11b84495ea1e54acdb6ffe2e83824a3708070c4035031" for token ending in 1I9pZ
Check 3: installation #18899821 got etag W/"86e2b5993179875ad7e54a85855c6244ec0e00e42066dd8d46c0e19f2f41a4b7" for token ending in Le7Hd
Check 4: installation #18899821 got etag W/"86e2b5993179875ad7e54a85855c6244ec0e00e42066dd8d46c0e19f2f41a4b7" for token ending in Le7Hd

This code is sending a request to the GET /orgs/{org}/repos REST API endpoint, but I see the same with all endpoint that I've checked.

I see the same behavior when sending a request with different personal access tokens for the same user. But personal access tokens may be long lived, while installation access tokens expire after only 1h.

[Hamed-Hasan]

const { App, Octokit } = require("octokit");

main();

async function main() {
const app = new App({
appId: process.env.GITHUB_APP_ID,
privateKey: process.env.GITHUB_APP_PRIVATE_KEY.replace(/\n/g, "\n"),
});

const { data: appInfo } = await app.octokit.request("GET /app");
console.log(Authenticated as ${appInfo.html_url});

const [firstInstallation] = await app.octokit.paginate(
"GET /app/installations"
);
console.log(
Installation ID #${firstInstallation.id} for ${firstInstallation.account.login}
);

// Cache the installation access token
const installationAuth = await app.octokit.auth({
type: "installation",
installationId: firstInstallation.id,
refresh: true,
});

// Use the cached token for subsequent requests
const octokit = new Octokit({
auth: installationAuth.token,
});

// Perform your checks with the same token
await check(1, firstInstallation.id, octokit, installationAuth.token);
await check(2, firstInstallation.id, octokit, installationAuth.token);
}

async function check(number, id, octokit, token) {
const {
headers: { etag: etag1 },
} = await octokit.request("GET /orgs/{org}/repos", {
org: "community",
});

console.log(
Check ${number}: installation #${id} got etag ${etag1} for token ending in ${token.slice( -5 )}
);
}

[gr2m]

are you trying to tell me something?

[gr2m]

If your suggestion is to cache the installation token, that won't help me, because installation access tokens are only valid for one hour, and I need to send requests over the span of days.

[github-actions[bot]]

🕒 Discussion Activity Reminder 🕒

This Discussion has been labeled as dormant by an automated system for having no activity in the last 60 days. Please consider one the following actions:

1️⃣ Close as Out of Date: If the topic is no longer relevant, close the Discussion as out of date at the bottom of the page.

2️⃣ Provide More Information: Share additional details or context — or let the community know if you've found a solution on your own.

3️⃣ Mark a Reply as Answer: If your question has been answered by a reply, mark the most helpful reply as the solution.

Note: This dormant notification will only apply to Discussions with the Question label. To learn more, see our recent announcement.

Thank you for helping bring this Discussion to a resolution! 💬

[gr2m]

I confirmed that etag hashes depend on the access tokens that are used. If a token changes, so does the etag. No way around it 😭

[mikebroberts]

Thanks @gr2m . I just spent a couple of hours being very confused, thought this was the case, and you've confirmed it. :) Do you have any idea how https://docs.github.com/en/rest/using-the-rest-api/best-practices-for-using-the-rest-api?apiVersion=2022-11-28 gets updated for this? Would be a very useful addition.

[gr2m]

Very good point, I'll raise it with the docs team when I get to it (not any time soon 😞). If anyone feels so inclined, please rise an issue at https://github.com/github/docs to get the ball rolling

[mikebroberts]

@gr2m - Issue created - github/docs#34689