[Bug]: Run analysis > area exposed fails

[wadhwamatic]

What happened?

If I run an analysis of any hazard layer with the statistic 'area exposed', I get a failed to fetch error

Which country / deployment are you running?

any country on main. reproduced with jordan, mozambique and rbd

Add a screenshot (if relevant)

[wadhwamatic]

@ericboucher - I'm not sure when this was introduced. Is PR #1327 related? cc @gislawill

[gislawill]

I did some digging into this, here's what I found:

• I wasn't able to run this locally in it's normal way because it requires storing cached files in AWS
  • So I bypassed the storing the cached files in AWS and just stored them locally in my filesystem
  • This mostly worked
• Much later on in the functionality, I ran into an error in zonal_stats in which the "nodata" field in clean_stats_properties[f"{safe_prefix}nodata"] was not defined
  • This error occurred in all stats
  • The values in clean_stats_properties were {'stats_min': 1.0, 'stats_max': 2.0, 'stats_mean': 1.0845070422535212, 'stats_count': 71, 'stats_sum': 77.0, 'stats_std': 0.27814672757931685, 'stats_median': 1.0, 'stats_intersect_pixels': 71.0, 'stats_intersect_area': 6.6456}
• I then commented out the "+ nodata" part of zonal stats (line 411 in zonal_stats) which allowed everything to run through through as expected for all stats (including area exposed)
  • I see this same behavior both before and after Adding reprojection step in calculate_stats if geotiffs' and stats borders' crs don't match; COUNTRY=mozambique #1327

So, not super conclusive. Leads me to believe there may be an issue related to when this "nodata" is defined vs when it is not.

I think next steps should be to look into the logs of the prism server to see if there is a specific error message that can give better direction