Cache Google Jobs listing with different queries
complete
Y
Yulia Tsernant
Hi, in the documentation for Jobs Listing API says "A cache is served only if the query and all parameters are exactly the same."
I tried to get job details for different jobs, passing different job IDs, but the returned result was the same.
It returned a result for a specific job id that was cached.
Queries tried:
Also attaching a screenshot if it will help. There are very similar, but different ids in my query and returned result.
Zil
complete
We have fixed the caching issue.
Other important changes made:
* Fixed
job_id
generation in google_jobs
engine. Previously salary
and apply_options
might not have been extracted with it.* Fixed
ratings
extraction in google_jobs_listing
engine.I would advise to get new
job_id
with google_jobs
engine to use with google_jobs_listing
engine to get the most precise results.Zil
in progress
We have identified the issue and we are working on a fix. It is indeed a cache problem that affects only
google_jobs_listing
engine.As a temporary workaround, you can disable cache by passing
no_cache=true
parameter until the fix is made.Elizabeth Oster
planned
Elizabeth Oster
Yulia Tsernant Hi,
Sorry about the issue.
Would you be able to share the search IDs of these 2 searches with me?
I believe I've reproduced the issue using your search links but I also want to make sure to document the issue with the examples you came across.
I'm not completely sure it's related to the cache yet. I've had instances where I got results for s different
job_id
consistently but it wasn't from a cached results. Regardless, we'll be sure to get to the bottom of it, I just want to be sure and document it with all of the info that I can.
Y
Yulia Tsernant
Elizabeth Oster: Hi Elizabeth,
here are ids that return the same result if I use them in query:
EyJobci6iMvUiiWiZMMiOijfb1fcq2x3d1LuvKLWmk5wwkDoeFvQRJZLaMHCTLv4AvDusLRPSG93vvvvFnTEfBnsGW1zFrWQ00YVzLLvWtAsWj5mu5avkz4vwTwa2fxmxfkm2h4zHpOnFzRtJnABUzkzgtJ5mU5avkz4vwTwa2fxmxfkm2h4zHpOnFzRtJnABUzGtZgTj5mU5AvkZ4vwTwa2fxmxfkm2h4zHpOnFzRtJnABUzGtZgTj5mU54TlgYSjZWvfK0WkVsLuzBhrSv2HaWhPoUVdSSvHWM0PCv2XSTWvqaEnOrfKwTuZCrLvDMWzREKYXUvZfYUN5MxjZeLzGvW1GcmiWeFiILCJMY3yIOIIYIWIZmFAWQIOIJMY18zocisimfwcgx5XpbmsiDGl0bguioijbchbsESbvbibhzxr0aw5niehpcmvkiiWiBgLuayi6imh0dhbzoi8vd3D3LMdLDHRpbmdoaxjLzC5jb20vAM9iLwRLDgfpbhmvmjg1mtewni9hbmfwbgfulw1vzgvslwj1awxkzxivp3v0bv9hbmfwbgfulW1VzgVsLwJ1V0bv9jyw1wywlnbj1nb29nbgvfam9ic19hchbsevx1mdaynnv0bv9zb3vyy2u9z29vz2xlx2pvynnfyxbwbhlcdtawmjz1dg1 Fbwvkaxvtpw9yz2fUawmiFx0
EyJobci6iMvUiiWiZMMiOijfBnDLvKrCaE4YMuXiBWhWVdnWUJJrElZiWTi0nVIxBe9HalzHyMtStLqXvJzSRkZnYnPJnVgWrKZiMTXu21gCLLXUJbARXhgwM1FeLjqrnfjeljRtUzCrLzYAZnABLjSvDE4mLxUjBarXhgwM1fELJQrLzYAZnABLjSvDE4mLxUJbArXhgwM1fELJQrLzYAZnABLjSvDE4mLxUJbARxHgWm1fELjQZrBzvJWfPrv0u5tWfcSvHzVJg0v1zSuU0zZeHxVk54tLu1DLvHCEPoBePwuVzFYUmYeEnsaZFOTJnKWFiWvK4ILcJmY3yIOiiYiWiZmNFAWQIOIJMY182ocisimfwcgx5X2XpbmsionSidgL0bGuioijBsEbVk5X2XpBSEsBvk4iLcJmY3yIOiYiWzMfWcGx5X2XpbmsionSidgL0bUiYBsEbVk5X2XpBSEsBvK5X2XpBSEsBvbibmaw5rZWrJBiiSiMXpbmsioijodhrwczovL3d3Dy5SaW5rZWrPBi5jb20vam9iCY92awv3L2fUYxbSyW4tchJHy3rPy2UtBgVhZgvYLWF0LxNSYWxVBS0YMZi4MzIv0bv9jyw1wyWlnbj1nb29nbgvfam9ic19hchbsevx1mDaYnNV0bv9zb3vyy2u9z29vz2xlx2pvynnfyxbwbHLcdtawmjz1dg1fbwvkaxvtpw9yz2 fUawmiFx 0 =
Eyjobci6iMvUiiWiZMMiOijfBJRLvMPCAE5sBe9IBWhyVdnVEwJJrELiT0C0m1IxBe9HRFzGWMTStMrWvXHsrkZnYnPGA1gwskjtVE4xvdjgdlywOwBu5czfcwm1fswjvuALyXu1vSvY25abfpWGyzvure5UUJJWBGNUWLjfAgRoWhPoWLDWQXPKMGravtnfmvrTovFHa2SYVW1SQLvsB0xvrTb6vXpSmFjUrJrXrVUILCJMY3yIOIIYIWIZMNFAWQIOIJMY183NiiSiMfWCgX5X2XpSiMSIdGL0bGuioIjBsBsBbIjmbmdlbexpc3qilcjsaw5riJoiahr0chm6ly9hbmdlbc5jby9jb21wyw55L2fUYxBSYW4VAM9iCy8XMjAZLXJLYwTzXn0yxrLLxn0cmf0zwd5lwfuzc1vcgvyyxrpb25zlw1hbmfnzxi/rtdxX2nHbXBHaWdUpWdvb2dszv9qb2jzx2fwcgx5xhuwmdi2dxrtx3nVdXJJzt1nb29nbgvfam9ic19hchBSEVx1 mDaYnNV0bv9tZWrPdw09b3jnyw5pyyj9fq==
if I add no_cache=true, it returns corresponding details for each job id
Elizabeth Oster
Yulia Tsernant: Sorry, I was referring to the search IDs for these searches not the
job_id
.The search ID can be found in the JSON under
search_metadata
. Here's an example: "search_metadata": {
"id": "6019c5e13d91e99c66e8e9db",
"status": "Success",
"json_endpoint": "https://serpapi.com/searches/6eccd428d7da60f9/6019c5e13d91e99c66e8e9db.json",
"created_at": "2021-02-02 21:36:33 UTC",
"processed_at": "2021-02-02 21:36:33 UTC",
"google_url": "https://www.google.com/search?q=Coffee&oq=Coffee&uule=w+CAIQICIaQXVzdGluLFRleGFzLFVuaXRlZCBTdGF0ZXM&hl=en&gl=us&sourceid=chrome&ie=UTF-8",
"raw_html_file": "https://serpapi.com/searches/6eccd428d7da60f9/6019c5e13d91e99c66e8e9db.html",
"total_time_taken": 1.78
You can see the search ID in this example is
6019c5e13d91e99c66e8e9db
This lets me look at the exact searches that went wrong in the first place so we use them for troubleshooting issues like this.
Elizabeth Oster
under review