Looks like this has never been fixed, I was checking my rooms after a long inactivity period and I can still see it happen.

Here is i posted on slack last night, with my findings

I have a room (W61S45) with disabled structures (extensions). That room reports energyAvailable < energyCapacitAvailable (1750<1800). BUT Game.rooms.W61S45.find(FIND_STRUCTURES, {filter: { structureType: STRUCTURE_EXTENSION }}).filter(s=>s.energy < s.energyCapacity && s.isActive()) reports no extension.

looks like the extensions counted for energyAvailable are not the active ones, anyone faced this already ? (notable to say that the displayed status of the extensions is off too, extension at 39,14 is shown active , but isActive returns false, meanwhile the one at 43,14 is the opposite [active but showed inactive])

This should be fixed so that inactive status of structures is consistent across the various APIs ... Due to the highly inefficient way isActive() is implemented, you can't expect players to have to call it every time (especially as the implementation lets me think the order may not be consistent over time either).

As my code will only spawn creeps when energyAvailable == energyCapacityAvailable the only way out I found is to refill all extensions, including inactive ones which is a shame

@Mashee neither : ) I'm actually running a timer based system. whenever a creep is spawned, a timer is set to determine when a new one needs to spawn, thus sparing the cpu cost of checking untill that time. this is why this issue is particularly hurting me

@SandGrainOne by construction my code should only ever spawn 1 creep per tick and per room. But yes, your point is valid

@Mashee thanks for the willingness to help, but there is no caching involved here, i'm storing in (saved) memory every spawn request i'm expecting to succeed, and checking that it was realized on the next tick, otherwise resubmitting it.

Had to do that because of the issue i describe above, which was resulting in some critical creeps missing

isn't that "getUniqueName" belonging to your code ?

you're definitely right ! i'll fix this, although this is not explaining the issue

the issue with this active check is how it's implemented : the engine searches for all structures , sorts them by range to the controller and returns true/false based on that .... but it's NOT cached.

This is especially bad for extensions as you can imagine, if you want to test which extensions are active and you have 40 of them, you'll do this check (sorting, checking if the current extension is in the allowed set) for EACH of them

i am not 100% certain but the code shouldn't allow it, i'm only spawning 1 creep per room per tick.

AND, the next tick the spawn isn't spawning anything else either (eg, spawn.spawning === undefined)

I'm not sure why all the fuss ?

If you intend to send creeps on a different shard, just allocate some cpu to it before ? now that we have the api it shouldn't be an issue right ?

So ... I'm trying to understand why some creeps don't spawn.

Are there cases where the creep won't spawn (eg, spawn.spawning is null on next tick) even though spawn.createCreep returned the provided name ?

This seems to happen quite often and is quite disruptive for my codebase,

How i came up to that conclusion : whenever I call spawn.createCreep and it returns ok I remember the request

	let result = this.createCreep(body, name, memory);

	let success = result === name;
	if (success) {
		Memory.spawning = Memory.spawning || {};
		Memory.spawning[this.id] = {name: name, time: Game.time, needTime: body.length / 3, result: result};
	}

Then on next tick I check if that spawn is spawning

function checkSpawns() {
	let failed = false;
	_.forEach(Memory.spawning, (expected, spawnId) => {
		let spawn = Game.getObjectById(spawnId);
		if (spawn && (!spawn.spawning || spawn.spawning.name !== expected.name)) {
			failed = true;
			expected.failed = true;
		}
	});
	if (failed) {
		Memory.failedSpawning = Memory.failedSpawning || {};
		Memory.failedSpawning[Game.time] = Memory.spawning;
	}
	delete Memory.spawning;
}

Ir remember the whole spawn requests because i wanted to make sure there was not name conflicts

Current output

{
  "21066868": {
    "5800c9308a798b425be34e2c": {
      "name": "bridge-867-W55S43",
      "time": 21066867,
      "needTime": 3,
      "result": "bridge-867-W55S43",
      "failed": true
    }
  },
  "21067841": {
    "580feb31ba239b7c48519603": {
      "name": "tractor-1840-W52S41",
      "time": 21067840,
      "needTime": 16,
      "result": "tractor-1840-W52S41",
      "failed": true
    },
    "59880854ae5de95797792478": {
      "name": "tractor-1840-W76N67",
      "time": 21067840,
      "needTime": 16,
      "result": "tractor-1840-W76N67",
      "failed": true
    }
  },
  "21067980": {
    "583090f06fba44674ac260ed": {
      "name": "bridge-1979-W57S45",
      "time": 21067979,
      "needTime": 3,
      "result": "bridge-1979-W57S45",
      "failed": true
    }
  }
}

so ... down to my question : are there cases where the spawn intent won't be executed on server side ? I've checked also that the energyAvailable on next tick was enough for the creep to spawn

found the faulty calling site ... was calling PathFinder.search ([pos: undefined, range: x])